Zugang zu meiner elgg installation ist nicht mehr möglich

http://www.s.chb.cc/s/

Nachdem ich alle plugins ausser die core plugins in ein seperates Verzeichnis verlegt habe, die .htaccess nochmals neu mit der htaccess_dist überschrieben habe bin ich am Ende meines Lateins.

Deshalb habe ich jetzt eine neu Installation angelegt und will zumindest die User Dtaen retten. Dazu habe ich die tabelle users_entity aus der alten DB exportiert und in die neue DB importiert. Die User werden aber in meiner neuen elgg installation nicht angezeigt.

Was habe ich falsch gemacht?

Für jeden Hinweis bin ich sehr dankbar.

  • Einzelne Tabellen aus einer Elgg-Datenbank herauszunehmen und in eine neue Installation zu übernehmen ist wahrscheinlich nicht zielführend, da Abhängigkeiten zwischen den einzelnen Tabellen bestehen.

    Die Frage ist: was hat dazu geführt, dass Deine Seite nicht mehr richtig funktioniert? Sowohl unter http://www.s.chb.cc/s/ als auch unter http://www.s.chb.cc/ erscheint eine Elgg-Indexseite (auch wenn bei beiden das Layout aufgrund nicht gefundenen CSS-Klassen fehlerhaft ist).

    Hattest Du versucht, den Installationsort auf dem Server zu ändern oder hast Du sonst irgendwelche Änderungen am Domainnamen, dem Ort des Datenverzeichnisses durchgeführt oder Redirects erstellt in Folge dessen Deine Seite nicht mehr funktioniert?

    Es sollte möglich sein, die ursprüngliche Installation zu retten oder zumindest mit der alten Datenbank und dem alten Datenverzeichnis eine neue Installation zu erstellen. Im Grunde wirst Du ähnlich vorgehen müssen wie beim Umzug einer Elgg-Seite von einem Server auf einen anderen: http://docs.elgg.org/wiki/Duplicate_Installation. Auch wenn die Elgg-Seite nicht umgezogen wurde solltest Du diese Anleitung durcharbeiten und prüfen, ob bei Deiner Installation die einzelnen Punkte stimmig sind (z.B. die entsprechenden Einträge in der Datenbank für Seiten-Url, Pfad zum Datenverzeichnis usw. den Ist-Zustand auf dem Server entsprechen).

    Das Überschreiben der .htaccess mit dem Inhalt von htaccess_dist kann auch zu Deinem Problem beigetragen haben. Bei der Url http://www.s.chb.cc/s/ ist davon auszugehen, dass das Elgg-Installationsverzeichnis in einem Unterverzeichnis namens "s" im Document Root-Verzeichnis ist. In diesem Fall mußt Du die in der .htaccess die RewriteBase entsprechend anpassen.

  • iionly Deine Tipps sind richtig wertvoll!

    Ich habe wohl dummerweise die Redirects geändert gehabt und jetzt komme ich immerhin schon wieder ins System.

    Aber jetzt habe ich noch immer keinen Zugriff auf die CSS-Klassen.

    Alle im engine Verzeichnis enthaltene Verzeichnisse haben die die Zugriffsrechte 755 und alle Files darin 644. Das ist ja wohl richtig.

    Was kann ich jetzt noch untersuchen um mein Layout wieder zum laufen zu bekommen? 

  • Es muss "alles" zueinander passen, damit es läuft:

    • RewriteBase in .htaccess gecheckt? Müßte wohl für die Seite gesetzt werden, da in subdirectory installiert: "RewriteBase /s/".
    • Pfad zu Datenverzeichnis korrekt? Am Ende des Pfades ein / eingeben, da es sonst eventuell Probleme geben könnte.
    • Zugriffsrechte des Datenverzeichnisses und aller Unterverzeichnisse und Dateien darin korrekt? Der Webserver muss lesen und schreiben können. Eventuell muss 777 gesetzt werden, falls owner und group für das Datenverzeichnis und seine Dateien nicht dem Account entsprechen, unter dem der Webserver läuft. Wenn das Datenverzeichnis nicht innerhalb des Document Root-Verzeichnisses liegt (wo es eh nichts verloren hat), ist das sicherheitstechnisch okay. Die CSS- und JS-Dateien werden im Datenverzeichnis gecacht. Wenn der Zugriff auf das Datenverzeichnis fehlschlägt oder der Pfad nicht stimmt, wäre das fehlende Layout zu erklären.
  • Hi iionly,

    nochmals vielen Dank für Deine Tipps denn Sie haben mich zum nachdenken gezwungen.

    Grund für die ganze Misere - ich hatte ein fehlerbehaftetes Modul installiert. Danach hat elgg automatisch die Zugriffsrechte sowohl auf die DB als auch auf die freien Daten wie mit folgender Fehlermeldung gesperrt (siehe Anhang). 

     

    Selbst eine Korrektur der Rechte auf die jeweilegen Verzeichnisse konnte keine Abhilfe schaffen.

    Letztendlich hat folgendes zum Erfolg geführt:

    1) Komplette Datensicherung neu eingespielt

    2) Das mit den Rechten 777 offene Datenverzeichnis "DATA" vom Originalverzeichnis in ein Unterverzeichnis verschoben.

    3) Die htaccess_dist kopiert und in .htaccess umbenannt

    4) Die eigene elgg Anwendung als Admin gestartet, was zur Folge hatte, dass ein neues offenes Datenverzeichnis "DATA" angelegt wurde mit den Unterverzeichnissen:

    • views_simplecache
    • system_cache

    5) Ins "DATA" Verzeichniss habe ich alle noch fehlenden Verzeichnisse und Datenfiles aus dem Original "DATA" Verzeichnis übertragen.

    6) Alle Zusatzplugins noch einmal nachinstalliert.

    Bis auf DokuWiki und Groups funktioniert soweit alles wieder.

    Christian

    sogln.com

    Anhang:

    Mit "  " eingeschlossene Einträge wurden von mir nachträglich neutral abgeändert!

    Schwerwiegender Fehler.

    Die Weiterleitung ist fehlgeschlagen, da der Seiten-Header bereits gesendet wurde. Die Ausführung wird sicherheitshalber gestoppt. Die Ausgabe wurde in der Datei /"db"/"subdomain"/s/languages/fi.php in Zeile 1 begonnen. Bitte gehe zu http://docs.elgg.org/ für weitere Informationen. 

    SecurityException Object
(
[message:protected] => Die Weiterleitung ist fehlgeschlagen, da der Seiten-Header bereits gesendet wurde. Die Ausführung wird sicherheitshalber gestoppt. Die Ausgabe wurde in der Datei /"db"/"subdomain"/s/languages/fi.php in Zeile 1 begonnen. 
[string:Exception:private] => exception 'SecurityException' with message 'Die Weiterleitung ist fehlgeschlagen, da der Seiten-Header bereits gesendet wurde. Die Ausführung wird sicherheitshalber gestoppt. Die Ausgabe wurde in der Datei /"db"/"subdomain"/s/languages/fi.php in Zeile 1 begonnen. 

    In /"db"/"subdomain"/s/engine/lib/elgglib.php:159

    Stack trace:
#0 /"db"/"subdomain"/s/actions/admin/plugins/activate.php(51): forward('admin/plugins#x...')
#1 /"db"/"subdomain"/s/engine/lib/actions.php(97): include('/chblbqxq/www.s...')
#2 /"db"/"subdomain"/s/engine/handlers/action_handler.php(20): action('admin/plugins/a...')
#3 {main}
[code:protected] => 0
[file:protected] => /"db"/"subdomain"/s/engine/lib/elgglib.php
[line:protected] => 159
[trace:Exception:private] => Array
(
[0] => Array
(
[file] => /"db"/"subdomain"/s/actions/admin/plugins/activate.php
[line] => 51
[function] => forward
[args] => Array
(
[0] => admin/plugins#xgadget
)

    )

    [1] => Array
(
[file] => /"db"/"subdomain"/s/engine/lib/actions.php
[line] => 97
[args] => Array
(
[0] => /"db"/"subdomain"/s/actions/admin/plugins/activate.php
)

    [function] => include
)

    [2] => Array
(
[file] => /"db"/"subdomain"/s/engine/handlers/action_handler.php
[line] => 20
[function] => action
[args] => Array
(
[0] => admin/plugins/activate
)

    )

    )

    [previous:Exception:private] =>

  • Oje!

    Wenn ich gewußt hätte, was genau das ursprüngliche Problem war, hätte ich Dir sagen können, dass eine Neuinstallation nicht notwendig gewesen wäre.

    Der Grund für den Fehler (im Plugin) ist ein Fehler in der Datei /"db"/"subdomain"/s/languages/fi.php. Was genau der Fehler ist, kann ich nur anhand der Fehlermeldung nicht sagen. Wahrscheinlich ist, dass diese Datei mit einem Encoding mit BOMs (Byte Order Marks) abgespeichert wurde. Die BOMs sind Steuerzeichen, die nicht dargestellt werden und in Language-Dateien von Elgg dürfen sie nicht drin sein, da dies zu Problemen führen kann. Also, Language-Dateien immer in "UTF-8 ohne BOM" abspeichern. Oder in der Datei war ein anderer PHP-Syntax-Fehler drin oder ein echo-Befehl, der da drin nichts zu suchen hat.

    Normalerweise hätte das Löschen dieser Datei bereits reichen sollen, damit die Seite wieder funktioniert (oder nach Entfernen noch ein zusätzlicher Aufruf von http://deine.seiten.url/upgrade.php um den Seitencache zu leeren). Falls ein fehlerhaftes Plugin dazu führt, dass die Seite gar nicht mehr funktioniert, kann man auch im mod-Verzeichnis eine Datei erzeugen, der man den Namen "disabled" gibt. Wenn eine Datei diesen Namens vorhanden ist, werden alle Plugins inaktiv und man kann sich wieder einloggen, dann das problematische Plugin deaktivieren. Wenn man die "disabled"-Datei wieder entfernt, sind alle anderen Plugins dann wieder aktiv.

  • Hi iionly,

    ich denke solch eine Lehrzeit macht gar nichts, denn ich habe dabei sehr viel über elgg gelernt. Vor allem wie zuverlässig die Passwörter der User geschützt sind. Und dies ist ja heute mehr denn je wichtig um wieder Vertrauen im Internet herzustellen. Mit Deinen neuen zusätzlichen Tipps profitieren vielleicht auch andere, die einmal vor einem ähnlichen Problemen stehen.

    Danke nochmals

    Christian

German Support Group

German Support Group

The German support group within the Elgg community.