<Gelöst> Upgrade auf 6.15 durch core files Dubletten nicht möglich... Wer hat eine Idee?

hi thorsten
kannst du den Ordner nicht einfach per FTP löschen?
oder mit Deinem webadmin?
oder per php

beispiel:
http://aktuell.de.selfhtml.org/artikel/php/verzeichnisse/

viel glueck
Stefan

Nein... Geht so einfach leider nicht, da Drupal dann nichts mehr rafft. Da der sites/all/modules den /modules überlagert (habe ich beim ersten Versuch merken müssen, erwartet Drupal die Dateien nun dort... :-(

Hier ist ein Fuchs mit dem Wissen um Datenbankbereinigung bzw. Pfadgeschichten gefragt....

hi,

wenn Drupal doch partou das Module haben will, dann würde ich ihm das Modul doch erstmal geben
also unter /sites/all/modules das Modul (ich nehme an das es dieses ist) abzulegen.

Wenn das Drupalsystem dann wieder läuft, könntest du das Modul ggf anschließend deaktiviern sofern gewünscht.

Ist nur so ne Idee, was mir bei der Fehlermeldung und deiner Situationbeschreibung als Versuch in den Kopf käme, daher ohne Gewähr (Sicherung vom aktuellen stand machen usw ;) )

Hallo Thorsten

die Pfade (base url) wird in der sites/all/settings.php gesetzt
und nicht in der datenbank gesetzt (kann ich aber nicht
für alle Module beschwören..)

hast du denn Zugriff auf den mysql server
zb ueber phpmyadmin?
Da kannst du doch eine Suche 'starten' nach den falschen Pfaden
und entsprechend Updaten.

Aber ich würde an Deiner Stelle versuchen den content zu retten
http://drupal.org/project/backup_migrate
und das drupal neu zu installieren

viel Glück
Stefan

@Methos
Hab' ich inzwischen auch schon probiert.

Habe diesen www.example.com/sites/all/modules/drupal.6.14 Ordner wieder hochgeladen und nach und nach alle contributed Module deaktiviert. Aber selbst ohne custom und contributed modules kann ich den Ordner nicht einfach löschen. Die Fehlermeldung sieht dann eben nur immer anders aus, der Erfolg ist aber stets gewesen, daß das System ohne diese Dateien dann den Dienst versagte...

Ziemlich verzwickt und mit meinen bisherigen Kenntnissen nicht lösbar....

Ich könnte bestimmt den falsch positionierten Ordner auf 6.15 updaten aber das kann wohl auch nicht im Sinne des Erfinders sein...

Wenn ich nur wüßte, wie man Drupal mitteilt, daß es sich doch bitte wieder der Dateien in www.example.com/modules zu bedienen...

Ich würde die Doublette versuchshalber löschen und danach die update.php aufrufen.

Genau das ist leider nicht möglich. Sobald die Dublette fort ist, kann ich keine Seiten (auch nicht update.php) aufrufen. Das genau ist ja mein Problem. Sorry, wenn ich das nicht klar rüber gebracht haben sollte...

Deine erste angegebene Fehlermeldung weist ja auf einen Konflikt mit dem "Localization client" Modul hin. Schon mal versucht das Modul zu deaktivieren, oder gar zu löschen?

Falls noch nicht geschehen, wäre es wohl auch ansonsten ne ganz gute Idee, alle Zusatzmodule erstmal zu deaktivieren, bevor es an die eigentliche Aktion geht. Dann schon mal www.example.com/update.php im Browser öffnen ... und erst dann den überflüssigen Ordner entfernen.

Möglicherweise klappt ja dann das Aufrufen der update.php? Ne Garantie habe ich da leider nicht für!

--------------------
Design Probleme einfach mit FF und FIREBUG lösen!

Probier ich nochmal aus... Irgendwie muß es doch gehen.

Ich lade mir den ganzen Schmunz jetzt in eine frische (andere) lokale Installation und werde diese quälen... Mal schauen...

Hm. Ich hätte schwer vermutet, dass durch die update.php die Dateipfade der system-Tabelle neugeschrieben werden (denn dort sind ja die falschen Pfade für die Core-Module hinterlegt) - aber das passiert wahrsch. dann doch nur nur für die crontrib-Modulverzeichnisse unterhalb von default und all.
Dann aber, denke ich, ginge folgendes: die System-Tabelle einer frischen lokalen Installation exportieren (mit DROP TABLE) und in die Remote-DB importieren (so dass also die verbogene system-Tabelle quasi resettet wird). Danach müssten alle Zusatzmodule neu aktiviert werden und das sollte es (so ganz vom grünen Tisch weggesprochen) gewesen sein. Oder aber Du korrigierst die Pfade der Spalte filepath in der system-Tabelle überhaupt von Hand.

Habe einen Lösungsansatz von Drupal.org (Drupal security team) bekommen...

1. Das doppelte Lottchen entfernen
2. Sicherstellen, daß die Corefiles sich alle am richtigen (default) Platz befinden.
3. Folgenden Datenbank Query ausführen:

UPDATE system SET filename = substring(filename, 43) WHERE filename LIKE '%drupal-6.14%';

4. run update.php
5. modules reaktivieren

Eigentlich kaum zu glauben, daß es das schon gewesen sein soll... Scheint aber ganz gut zu klappen. Ich habe access, konnte update.php ausführen und die modules wieder reaktivieren. Mal schauen ob auch weiterhin alles geradeaus läuft.

Zunächst aber scheint's mal in Ordnung zu sein...

Möchte mich aber nichtsdestotrotz an dieser Stelle einmal recht herzlich für Eure Hilfsbereitschaft bedanken!

Drückt mir mal die Daumen!

Soooo... Scheint geklappt zu haben...

6.15 ist auf der lokalen Testumgebung installiert und wirft keine Fehler aus...

Nun stellt sich mir die Frage:

Durchlaufe ich die gleiche Prozedur auf dem Server oder lade ich Daten und Datenbank vom local hoch?

Allerdings ist noch etwas eigenartig:

Bei wirklich jedem Cronlauf kommt neben den Feeds folgende Meldungen:

# Updated string type:faq:title for textgroup nodetype: Question
# Updated string type:faq:body for textgroup nodetype: Answer
# Updated string type:faq:description for textgroup nodetype: A frequently asked question and its answer.
# Updated string type:image:name for textgroup nodetype: Image
# Updated string type:image:title for textgroup nodetype: Title
# Updated string type:image:body for textgroup nodetype: Body
# Updated string type:image:description for textgroup nodetype: An image (with thumbnail). This is ideal for publishing photographs or screenshots.
# Updated string type:dragon:body for textgroup nodetype: Description

Und zwar sind es tatsächlich immer die Gleichen. Wie kommt so etwas?