[gelöst] Umzug vom server auf XAMPP (Win): WARNING ...

Welche Version von XAMPP bzw. PHP hast Du installiert?
mit config.php meinst Du aber die settings.php, oder?

sorry, klar, ich meine settings.php. XAMPP-letzte Version, also 1.7.3. Ich vermute, das sind wirklich irgendwelche falschen Pfade, nur welche? Kenne mich mit php schlecht aus.

Da liegt der Hund begraben, viele Module haben Probleme mit der dort enthaltenen PHP Version 5.3.1, Du solltest XAMMP 1.7.1 mit PHP 5.2.9 installieren.

Ich habe nun die 1.7.1. version. Alles neu gemacht, DB neu installiert und zusätzlich zum ersten mal cache tabellen geleert (cache, cache_block, cache_filter) etc.
Aber kein resultat- immer noch der gleiche Fehler, der da auf den includes ordner verweist. nur weiß ich nicht, was er von mir will?

Was mir noch aufgefallen ist- die Icons im Adminpanel (admin template rootcandy) sind dunkelbalu markiert, in der online version gibt es keine markerung. Vielleicht kann das helfen, das Problem zu finden... http://easycaptures.com/fs/uploaded/400/6722131916.png

Was für eine Drupal Version ist das genau?

Hast Du schonmal ausprobiert, ein neues leeres Drupal im XAMMP zu installieren, dann kann man vielleicht manche Fehlerquellen ausschliessen?

Übrigens sagt Google das dazu:
http://drupal.org/node/414764

Vielleicht kommt man damit dem Fehler auf die Spur

Hi, es ist 6.16. Ja , verzweifelt würde ich alles neu installieren. Aber wie packe ich dann alle Dateien/DB etc. wieder rein? Denn testen kann ich nur mit der aktuellen Version, die momentan live ist. Sonst nützt es nicht viel.
Könntest du bitte kurz die wichtigsten Schritte beschreiben? Danke sehr!

Zuerst installiere folgendes Modul http://drupal.org/project/backup_migrate

Auf dem Server machst Du dann damit ein Backup der Drupalinstallation (vor dem Backup den Cache leeren) - dann kopierst Du alle auf dem Server verwendete Nicht-Core-Module nach Xampp /sites/all/modules rein.

Eine leere/neue Drupalinstallation unter Xampp installieren - aktiviere dann auch dort http://drupal.org/project/backup_migrate und spiele das Backup ein - alle benötigten Module etc. werden nun automatisch aktiviert.

Dann sieh nach ob die Fehlermeldung immer noch auftritt.

XAMPP version 1.7.1 läuft bei mir tadellos - mit anderen Versionen hatte ich auch nur Probleme.

hi, sorry, muss leider nochmal nachfragen.

1. SQL nach Cache leeren durch backup_migrate gesichert - OK
2. Nicht-Core-Module sind alle außer z.b. node, contact etc. gemeint, also, die die ich selbst installiert habe?
3. Unter Xampp: /sites/all/modules - in dem "all" ordner gibt es kein "modules". Aber unter /sites/all/default! Wo sollen denn nun die module hin?
4. Eine leere habe ich installiert (auf engl., aber ist trotzdem ok, oder?)- wie meinst du soll ich backup_migrate aktivieren- in der leeren Version von Drupal gibt es das modul noch gar nicht.

Freue mich aufs Feedback!!!

2. Ja

3. Leg unter "all" einfach den Ordner /modules an - der Pfad muss richtig lauten /sites/all/modules - dort kommen in Zukunft alle weiteren/neuen Module rein. NICHT unter default

4. backup_migrate kopierts Du nun in /sites/all/modules rein - dann schaust Du in Deine Drupalinstallation unter Module (eventuell reload) - dort backup_migrate aktivieren. Danach spielst Du über "Restore" das Backup ein. (nicht vergessen vorher alle benötigetn Module vom Server in die XAMPP-Installation zu kopieren weil mit dem Restore-Prozess gleichzeitig alle Module aktiviert werden - die Du auch auf dem Server laufen hast)

Falls Du die Nicht-Core-Moduel auf dem Server alle unter domain.com/modules kopiert hast, könnte es eventuell Problem geben wenn Du jetzt /sites/all/modules verwendest (bitte ausprobieren) - wichtig für die Zukunft ist aber alle Nicht-Core-Module immer nach /sites/all/modules kopieren

Schaue nun bitte nach ob die Fehlermeldung immer noch erscheint.

Ja, nicht-Core-Module sind alle Module, die nicht bei der normalen Drupal-Installation enthalten sind. Alle Module die im Ordner modules (also im Modules-Ordner des root-Folders) enthalten sind, sind Core-Module. Alle, die sich in sites/*/modules befinden, sind Contrib-Module.

sites/all/default? Was soll denn das sein? Es gibt den sites-Ordner und darin gibt es die Ordner all und default (und bei Multi-Site-Installationen noch weitere). Und in all sollten die Ordner themes und modules vorhanden sein und dort kommen alle Contrib-Module rein und nirgendwo sonst, außer du hast eine Multi-Site-Installation!
Die Ordner in sites/all musst du aber erst selbst erstellen.

Dann musst du natürlich das Modul in diese Installation einfügen und aktivieren.

danke euch!
1)Ich habe tatsächlich alle module im ordner .../htdocs/meineseitename/module und nicht in /htdocs/meineseitename/sites/all/modules. Das gleiche auch aufm Server. Oh je, bisher hat alles gut funktioniert. Soll/Kann ich es online ändern??

2)Nun zu XAMPP: Der Fehler war da, ich habe nun alle module überall reinkopiert, nach dem Motto "lieber mehr als gar nicht" und die Fehleranzeige wurde immer kleiner. Nun sehe ich nur das, solange ich nirgendwo im backoffice auf "speichern" oder "bearbeiten" gehe.http://easycaptures.com/fs/uploaded/400/6035848833.png
Irgendwas ist noch da mit dieser Zeile 1066. Ideen? Ich als Anfänger würde denken, etwas mit Blocks stimmt da nicht. Denn auch im Backend ist der von mir modifizierter Admin-Menü-Block nicht links sondern existiert nicht. so sieht es online aus: http://easycaptures.com/fs/uploaded/400/5841052321.png Liege ich da richtig und was kann ich sonst noch machen?

Ja, unbedingt! Vorher eine Sicherung anlegen und dann alle Contrib-Module (und auch nur die Contribs!) nach sites/all/modules verschieben. Evtl. musst du die Module vorher deaktivieren.

Sowas macht man nicht -,-' --> "Viel hilft nicht immer viel"

Bring erstmal die Installation in Ordnung, denn da scheinst du einiges durcheinandergebracht zu haben. Solange solche Dinge wie oben (Module sonstwo vorhanden) in deiner Installation auftauchen, kann man den Fehler kaum sinnvoll eingrenzen.

wie soll den ordner meineseite/moduls danach aussehen- leer oder nicht vorhanden sein? Soll ich also alle module - nachdem ich sie in sites/all/modules kopiert habe, löschen?
Also ihr meint, erstmal online die änderungen durchführen (module deaktivieren/verschieben) und erst dann das ganze unter xampp importieren?

Ach und noch was- woher weiß drupal, dass ich die module verschoben habe? müssen irgendwelche pfade geändert werden? und warum hats bisher immer gut funktioniert, auch wenn sie wo falsch lagen?

In meineseite/moduls bleiben nur die Core-Module (vergleiche sie zur Not mit dem entpackten jungfräulichen Drupal-Verzeichnis)

Es wäre ratsam die Nicht-Core-Module zuerst zu deaktivieren - dann nach sites/all/modules zu kopieren und anschließend unter meineseite/moduls zu löschen.

Danach admin/build/modules reloaden und die Module wieder aktivieren.

Das "merkt" Drupal automatisch. Es müssen keine Pfade geändert werden.

halt, halt, wie mach ich denn "reloaden"? Im Backend?? wie genau? (vielen vielen dank für eure geduld!)

Du sollst nicht alle Module aus dem modules-Ordner raus nehmen, sondern nur (!) die Contrib-Module.

Die schiebst du nach sites/all/modules und löschst sie aus dem Ordner /modules

Und vorher deaktivierst du die Module und aktivierst sie nach dem Verschieben wieder, damit dürfte auch die Sache mit den Pfaden intern geregelt sein.

Also:
Contrib-Module deaktivieren --> Contrib-Module nach sites/all/modules verschieben --> Contrib-Module aus /modules löschen --> Contrib-Module wieder aktivieren.

In dieser Reihenfolge und nicht anders. Nicht erst wieder aktivieren und dann löschen oder sowas.

Und wie gesagt NUR die Contrib-Module. Alles was zum Drupal-Core gehört (Node, Comment, Blog usw. Eben alles, was bei einer frischen Installation schon in dem Ordner ist) bleibt, wo es ist.

Ja und vorher Sicherung (Datenbank und Daten) anlegen.

Weil die Module natürlich trotzdem erkannt werden. Aber es gilt "Never touch the Core". Alle eigenen Dinge werden im sites-Ordner eingefügt, also in sites/all/modules oder sites/all/themes oder sites/default/files usw. Alles außerhalb des sites-Ordners wird niemals angefasst.

Außerdem bekommt man evtl. Probleme beim Core-Update, wenn man die Contrib-Module mit nach /modules packt.

Edit:
Reloaden: Einfach sites/all/modules nochmal aufrufen ;-)

@bernadine

Ja - im Backend - der Link "Module" - falls Du den Link geöffnet hast und dabei die Module verschoben hast, solltest Du die Seite reloaden!

bin gerade dabei, die ganzen änderungen durchzuführen. mir fällt noch was ein- soll das gleich mit den themes und evtl noch mit etwas gemacht werden??? oder kann ich es dann nachträglich tun, falls es nötig ist? ich habe natürlich auch komplett neue themes, also templaes.

Hallo,

ja - die eigenen Themes kommen auch unter "all"

Pfad wäre /sites/all/themes

Da die Theme-Ordner reinkopieren - Drupal erkennt sie dann automatisch und zeigt sie unter "themes" /admin/build/themes an.

Oh je, nun habe ich alle schritte durchgeführt, nur ohne themes, da ich ja schon dabei war.
erstmal sah alles gut aus - ich habe alle schritte gemacht+ module reloaded und wollte alle benötigten module aktivieren- und auf speichern geklickt: WEIßER SCREEN...

die webseite kann zwar selbst noch aufgerufen werden, aber überall dieser komische fehler: warning: require_once(sites/all/modules/modules/system/system.admin.inc) [function.require-once]: failed to open stream: No such file or directory in /web/1/000/046/320/178659/htdocs/meinseite/includes/menu.inc on line 346. - und zwar an der stelle wo der tex stehen soll. Text ist nicht mehr da. aber menüs etc. sind noch vorhanden.

panik!!!!!!

p.s. wie ist es übrigens mit den komischen dateien aus dem alten modules ordner: changelog.txt, instal.php etc.- sollen die auch in den sites/all/modules ordner reinkopiert werden? die habe ich dort nicht reinkopiert.

Klingt nach Memory_Error, ergo zu wenig PHP-Memory --> wie hoch liegt denn dein PHP_Memory_Limit?

Alle Module auf einmal zu aktivieren ist auch ein wenig... riskant.

Solche Dateien haben in diesem Ordner eigentlich nichts verloren, die müssen durch einen Fehler deinerseits dort hin gelangt sein.

Vielleicht solltest du das ganze Prozedere nochmal wiederholen und dabei die Module in kleinen Gruppen aktivieren und nicht alle auf einmal.

würde ich gern, nur ist da der weiße bildschirm, wenn ich in den admin bereich gelangen will.
das mit den modulen wusste ich nicht...

was kann ich denn nun tun?

Backup einspielen und nochmal versuchen.

bevor ich wieder etwas falsch mache: 1)backup ordner rüberkopieren (also überschreiben) und 2)die datenbank in phpmyadmin beim provider löschen und neu aus dem backup importieren??

p.s. wie hoch liegt denn dein PHP_Memory_Limit? - wo kriege ich denn das her, aus config.php? kann ich den wert selbst ändern?

Ja, oder alle vorhandenen Daten löschen und dann die Backup-Daten hochladen

Nicht löschen, sondern lieber leeren, das heißt, alle darin vorhandenen Tabellen löschen, aber nicht die Datenbank selbst! Bei Shared-Hosting wird meist der Datenbank-Name automatisch vergeben. Das heißt, wenn du die DB löschst und eine neue Datenbank anlegst, hat die einen anderen Namen und du musst die settings.php (die nicht config.php heißt) ändern.

Wenn du aber nur alle Tabellen in der DB löschst und dann in diese leere Datenbank die Backup-DB importierst, kannst du die settings.php lassen, wie sie ist.

Dazu musst du mal admin/reports/status/php aufrufen und nach dam Wort "memory" suchen, da dürftest du mal den Eintrag "php_memory_limit" finden. Dahinter steht dann dein gewünschter Wert.

Oder du legst eine neue Datei namens info.php an und kopierst folgenden Inhalt (inkl. PHP-Begrenzer) rein:

Die Datei kopierst du dann in das Stammverzeichnis deiner Drupal-Installation und rufst es über example.com/info.php auf (oder kopiere es nach sites/default/files und rufe example.com/sites/default/files/info.php auf, bleibt sich gleich). Mit dieser Datei bekommst du dann die gleiche Ausgabe wie unter admin/reports/status/php.

Kommt auf deinen Webhosting-Anbieter an, bei manchen geht's, bei anderen nicht. Bei wem hostest du denn die Seite?

Ja kannst Du ... im Ordner xampp/php findest Du die Datei php.ini

Die öffnest Du und schaust in Zeile 246

Dort steht memory_limit = (dein_wert)M

stell das bitte auf

memory_limit = 128M

Sollte es Probleme beim Aktivieren der ganzen Module geben, stelle zusätzlich in Zeile 244 den Wert auf max_execution_time = 180

Zeile 245 eventuell auf max_input_time = 90 (so hab ich das)

Danach muss der Apache neu gestartet werden bzw. Doppelklick auf xampp_restart.exe - nun läuft der Apache mit den geänderten Werten und Du kannst "Restore" (backup_migrate) nochmal starten. So müsste es funktionieren.

Myphp beim DB-Hochladen hat mir nun einen allgemeinen fehler angezeigt. Der Provider meinte- die datenbank ist evtl. zu groß (2,7Mb groß?). Nun habe ich sqldumper installiert. Der liest nur .sql und .gz. Die sicherungskopie, die ich gestern abend erstellt habe (mit von euch empfohlenem backup_migrate) ist -mysql und kann vom mysql dumper unter verwaltung/hochladen nicht gelesen werden.

Nun würde ich entweder die Endung einfach per hand ändern oder die DB aufm XAMPP installieren (das geht!) und die dann sichern. Aber ich frage lieber erstmal Euch.

Ähm - ich denke Du willst die Installation unter XAMPP zum Laufen bringen? Warum willst Du die DB nun wieder auf den Web-Server raufspielen? Dort ist sie doch schon vorhanden oder nicht?

Verstehe ich gerade nicht.

ich glaube, da hast du was verpasst. ;)

mir wurde gestern empfohlen, ordnung aufm server zu schaffen, da alle nicht-core modules waren im root und nicht unter sites/all/modules. So habe nach anweisungen alle nicht-core modules in sites/all/modules und am alten Ort diese gelöscht (nur core-modules dort gelassen). Als ich die module jedoch im admin bereich aktivieren wollte, ist meine DB zusammengebrochen, da ich alle aufeinmal angeklickt habe. Das war wohl ein Fehler.
Dann war der weißer Screen im admin-bereich überall. Und Frontend- nur Fehler ohne Ende statt des Textes.

Nun ist die Challenge- die Sachen aufm Server erstmal wiederzustellen. und da habe ich schon das nächste Problem. MysqlDump liest keine .mysql dateien. Wie lade ich denn da eine Sicherung hoch als .sql oder .gz?

Und hast Du schonmal versucht die Module erstmal wieder zurückzukopieren nach root/modules ? Damit das Problem mit dem "white screen of death" behoben werden kann?

Dein Webserver hat bestimmt eine zu niedrige Zeitbeschränkung "max_execution_time" sodass der Vorgang des Aktivierens der ganzen Module - vor erfolgreichem Abschluß - seitens des Servers abgebrochen wurde.

Wenn alles nichts hilft - neuen Unterordner -> frische Drupalinstallation rauf -> alle Module nach root/modules kopieren (so wie in der funktioniernden Version) -> DB per backup_migrate wieder raufspielen.

Falls das auch nichts bringt - den Hoster bitten die max_execution_time zu erhöhen und "memory_limit = 128M" zu stellen oder gleich Local auf Xampp machen.

Hast Du bei XAMPP die Anpassungen vorgenommen http://www.drupalcenter.de/node/28993#comment-103094

Ich vermute, dass auch unter XAMPP die Werte zu niedrig eingestellt sind, sodass das Einspielen des Backups nicht bis zum erfolgreichen Abschluß "durchläuft" sondern vorher abgebrochen wird. Dann treten natürlich die Fehlermeldungen auf. Ich glaube ich hatte das problem auch schon einmal (nachdem die Werte angepasst wurden, klappte es tadellos).

Eine weitere Möglichkeit wäre - bevor Du das Backup installierst - (unter XAMPP oder auf dem Webserver) - aktiviere zuerst die Module (nach und nach) - wähle immer 2 -5 gleichzeitg aus und aktiviere sie solange bis Du alle aktiviert hast (die Du auf der vorherigen lauffähigen Version auf dem Webserver einsetzt) - sobald Du damit durch bist - spiele das Backup über Backup_migrate ein. Damit müsstest Du das Problem mit der max_execution_time umgehen können da der Backup-Prozess wirklich nur die Datenbank installiert aber gleichzeitig die ganzen Module nicht auch noch aktivieren muss (die sind ja schon aktiviert).

- nein, habe ich nicht versucht, vom server ist alles weggelöscht, auch die DB. Und Backup -Dateien sind wieder hochgeladen, können jedoch nicht aufgerufen werden, da ich die ganze Zeit die DB nicht importieren kann.

Zeitproblem ist ja nur beim Hochladen der Datenbank in SQL. Meinst du, soll ich dafür auch Werte irgendwo in XAMPP ändern? Ich dachte, drauf hat nur mein hoster einfluss, wie lang das hochladen sein kann.

geht nicht, denn:
Status im Moment:
LIVE:
- Backup-Dateien hochgeladen, aber url ist nicht aufrufbar
- Denn: keine DB installiert
XAMPP:
- immer der alte Fehler im Admin Bereich, wobei ich dort nichts abspeichern/ ändern kann.

Ich versuche nun die backup-DB von backup_migrate in XAMPP hochzuladen, dann als gzip runterzuladen und LIVE in sqldump einzuspielen. Ist es ok? Oder verursache ich da eine Explosion?

Statusmeldung: Backup hat geklappt!

Schritte:
- sicherungs-dateien (also komplette seite) wieder auf den Server per FTP hochgeladen, nachdem ich das Verzeichnis gelöscht hatte
- .mysql unter XAMPP phpmyadmin hochgeladen
- daraus .gz exportiert
- in sqldumper die DB importiert (Verwalten/hochladen) - das hat nicht mal 2 min. gedauert ;)
- Die Seite war nun abrufbar :)
- Alle Module deaktiviert (davor screenshot gemacht, was bisher aktiv war)
- Nicht-Core-Module aus dem root-"modules" Verzeichnis (was ja falsch war!) in sites-all-modules verschoben
- Das gleiche mit den Themes gemacht
- Im Admin bereich alles nötige aktiviert.

Nun geht alles wie bisher.

Und ich glaube, ich versuche es nocheinmal bei XAMPP und falls es nicht klappt- lass ich es sein. Unzählige Stunden und Nerven gehen einfach verloren.
Danke aber Euch allen für die Unterstützung!

Schön zu hören. Am Anfang hatte ich so meine Probleme.

Denke bei XAMPP daran die Anpassungen vonzunehmen - vor allem memory_limit = 128M <- wichtig.

Bei mir läuft die importierte DB vom Webserver innerhalb Xampps problemlos.

Und zum Erstellen des Projektes ist das Arbeiten unter Xampp wesentlich angenehmer und geht schneller.

Ich bin mir jetzt nicht sicher obs hier schon erwähnt wurde, aber sicher is sicher:

Wenn du die Seite bei dir lokal installierst musst du unbedingt die Datenbank-Verbindung in deiner settings.php mit anpassen. Sollte die Datenbank deiner Produktivseite von Außen erreichbar sein, kann es passieren, dass du bei Änderungen, die du bei dir lokal machst, auch deine Produktivseite verändern.

Sollte das hier schon irgendwer geschrieben haben, bzw du weißt es selbst, dann hab ich natürlich nix gesagt :-)

es scheint zu funktionieren mit XAMPP! vielen dank nochmal an alle!

Sehr schön ;-)

Setze dann den Titel dieses Themas bitte auf [gelöst] ..

Gruß Matthias