Seite verschwunden
![](https://www.drupalcenter.de/files/imagecache/upic_mini/pictures/picture-4204.png)
am 04.06.2009 - 10:51 Uhr in
Hallo,
eine meiner Webseiten ist ohne Zutun verschwunden.
Zuerst gab es Fehler bei der Darstellung des Themes dann kam eine weiße Seite ohne Quelltext.
Gemacht wurde definitiv nichts...
Da mein Hoster im Moment intern ziemlich viel neu strukturiert, kam mir die Idee das es daran liegen könnte.
Dieser weißt jedoch alle Schuld von sich und schreibt mir folgendes:
Wir haben gestern das Problem abgeklärt und mussten feststellen, dass dieses mit dem Cache zusammenhängt.
Das Problem ist ein Scriptfehler und kann deshalb von uns nicht gelöst werden.
Laden Sie ggf. die Templates neu hoch, dies behebt bei anderen Scripten diesen Umstand.
Hat jemand von Euch schon mal Ähnliches erlebt?
Hat jemand einen Tipp für mich?
- Anmelden oder Registrieren um Kommentare zu schreiben
Pruefe mal das PHP Memory
am 04.06.2009 - 11:00 Uhr
Pruefe mal das PHP Memory Limit und erhoehe es gegebenfalls.
------------------------
Quiptime Group
Das liegt bei 32 im Moment.
am 04.06.2009 - 11:01 Uhr
Das liegt bei 32 im Moment. Eigentlich ausreichend...
Nicht ausreichend!
am 04.06.2009 - 11:15 Uhr
32 MB sind nicht ausreichend!
Ich empfehle Dir mindestens das Doppelte und wenn moeglich sogar mehr. Ab 92 MB bist Du auf einer sichereren Position.
------------------------
Quiptime Group
Ich kann das leider nicht
am 04.06.2009 - 11:27 Uhr
Ich kann das leider nicht selbst ändern, da der Kunde unbedingt einen eigenen Hosting-Acount wollte und sich für das billigste Angebot eines Hosters entschieden hat.
Der Hoster ist auch nicht bereit das Limit zu erhöhen.
Was kann ich jetzt tun?
Vorher lief die Seite über Wochen ohne Probleme.
Edit:
Was ist denn von der Aussage des Hosters zu halten, dass es sich um ein Cachingproblem handelt?
Geiz ist nicht immer geil.
am 04.06.2009 - 11:48 Uhr
Nochmal, 32 MB sind fuer D6 mit den normalen contributed Modulen wie CCK, Views, Image Cache keinesfalls ausreichend.
Wenn die Website bisher mit 32 MB funktionierte dann lief sie bisher sozusagen am Limit. Und nun ist es umgekippt. Das kann verschiedene simple Ursachen haben die nicht mit einem Fehler zu tun haben muessen.
Abgesehen davon muss es nicht das Memory Limit sein. Wenn, wie Du sagst, der Hoster am Server Aenderunge realisiert hat kann es auch dort Ursachen geben.
Die Auesserung des Hosters kann ich nicht bewerten. Wenn Du aber dem Wort Caching folgst dann stelle Dir die Frage wo das Caching stattfindet? Kann es der Memory sein?
Selbst wenn in der Drupal Administration kein Caching eingestellt ist wird von Drupal ein Caching realisiert - auf vielfaeltiege Weise in vielfaeltigen Zusammenhaengen. Insbesondere bei Drupal 6. Beispielsweise die Template Engine, Views, das Menuesystem u. weiteres.
Fazit:
Erklaere Deinem Kunden das Geitz nicht immer geil ist. Du sollst nun fuer den Geiz des Kunden gerade stehen. Oder?
------------------------
Quiptime Group
Der Hoster hat das
am 05.06.2009 - 12:33 Uhr
Der Hoster hat das Memory-Limit zum testen mal auf 64 gesetzt.
Keine Änderung...
Ich dreh hier gleich am Rad. Die Seite hat eine Menge Arbeit gemacht und stand kurz vor der Auslieferung.
Hat jemand eine Idee?
Eine hochgeladene Info.php
am 05.06.2009 - 13:11 Uhr
Eine hochgeladene Info.php zeigt folgendes:
http://markmann.info/php.php
Ist da irgendwas nicht in Ordnung?
Ich weiß das der Hoster Umstellungen vorgenommen hat.
Und ich weiß auch das es dort normal ist bei Problemen alle Schuld auf den Kunden abzuwälzen, bis dieser das Gegenteil bewiesen hat...
Ich denke als Memory Limit
am 05.06.2009 - 15:54 Uhr
Ich denke als Memory Limit sind 64 MB verfuegbar.
------------------------
Quiptime Group
Ja, jetzt. Die Seite zeigt
am 05.06.2009 - 16:04 Uhr
Ja, jetzt.
Die Seite zeigt weiterhin the WSOD...
Edit:
Wenn ich Dir die Zugangsdaten schicke, kannst Du mal nachsehen?
Ich bin völlig ratlos...
Was Du tun kannst ist alle
am 05.06.2009 - 17:11 Uhr
Was Du tun kannst ist alle contributed Module zu deaktivieren. Wenn Du nicht mehr einloggen kannst geht das auch ueber PHPmyAdmin in der Tabelle system, in dem man Module auf den Status 0 setzt. Man sollte dabei aber sehr bedaechtig vorgehen um nicht aus Versehen "falsche" Module zu deaktivieren.
Und dann mit der "blanken" Drupainstallation sehen ob der WSoD noch da ist. Wenn ja sollte dies ein Indiz fuer - Suche die Ursache beim Hoster - sein.
Wenn dann kein WSoD mehr da ist die Module wieder deaktivieren. Wobei Dir das letztenendes aber nichts bringen wird weil das vermutete Limit Problem weiterhin existiert.
Du haettest zwischendurch schon mal eine Liste aller aktiven Module posten koennen. Damit hat man einen etwas genaueren Blick auf das wovon eigentlich die Rede ist.
Bis zum Auftreten des WSoD gab es seitens der Drupalinstallation wirklich keinerlei Aenderungen? Es muessen ja keine weiteren Module sein die aktiviert wurden.
Auch eine fehlerhaftes Template kann die Ursache sein.
Koennen Redakteure beim Erstellen/Editieren von Nodes PHP Code ausfuehren?
Eventuell sind jegliche Errormeldungen seitens des Webservers deaktiviert. Das erschwert die Spurensuche enorm.
PS
Hat Dir der Hoster Zugriff auf die Webserver Errorlogs gewaehrt? Eventuell ergeben sich dort Hinweise.
------------------------
Quiptime Group
Hallo, hier zwei Fotos mit
am 05.06.2009 - 18:23 Uhr
Hallo,
hier zwei Fotos mit den installierten Modulen:
Bis zum Auftreten des WSoD gab es seitens der Drupalinstallation wirklich keinerlei Aenderungen? Es muessen ja keine weiteren Module sein die aktiviert wurden.
Nein, nichts.
Auch eine fehlerhaftes Template kann die Ursache sein.
Das kann sein, da sich erst die Template-Dateien verabschiedet hatten und dann die WSoD kam. Kann es was bringen das Template vom Server zu löschen?
Koennen Redakteure beim Erstellen/Editieren von Nodes PHP Code ausfuehren?
Nein.
Hat Dir der Hoster Zugriff auf die Webserver Errorlogs gewaehrt? Eventuell ergeben sich dort Hinweise.
Ich habe dorthin geschrieben und muss jetzt auf Antwort warten.
Das muss jetzt nicht
am 05.06.2009 - 20:35 Uhr
Das muss jetzt nicht unbedingt was mit deinem Whitescreen zu tun haben, aber Deine Module sind schon mal im falschen Verzeichnis ... sieht zumindest so auf Deinen Screenshots aus ...
eigentlich sollten Nicht-Core Module bei Dir unter /httpdocs/sites/all/modules/ sein! Sie sind aber anscheinend ALLE unter /httpdocs/modules/ ....
-------------------------------------------------------------------------------
Drupal ist das "Coolste", was mir in 10 Jahren Webworking untergekommen ist!
Mein aktuelles Drupal Projekt: STEELDART Dart Community
Thoor schrieb Das muss
am 05.06.2009 - 20:45 Uhr
Das muss jetzt nicht unbedingt was mit deinem Whitescreen zu tun haben, aber Deine Module sind schon mal im falschen Verzeichnis ... sieht zumindest so auf Deinen Screenshots aus ...
eigentlich sollten Nicht-Core Module bei Dir unter /httpdocs/sites/all/modules/ sein! Sie sind aber anscheinend ALLE unter /httpdocs/modules/ ....
-------------------------------------------------------------------------------
Drupal ist das "Coolste", was mir in 10 Jahren Webworking untergekommen ist!
Mein aktuelles Drupal Projekt: STEELDART Dart Community
Also halte mich jetzt ruhig für bescheuert... Das wusste ich nicht. Bisher habe ich das immer so gemacht...
Warum ist das nicht richtig?
Moduleordner von eigenem Theme und Module
am 06.06.2009 - 08:21 Uhr
Hallo zusammen,
sorry wenn ich hier einfach vorgreife, habe gerade so schön eine Antwort parat :-)
Dass man die Module unter sites/all/modules anlegt, hat nicht zuletzt auch mit dem Siteaufbau an sich zu tun.
Angenommen du möchtest ein eigenes Theme machen, oder eine Multisite versuchen. Da bist du dann um diese Struktur froh, weil z.B. so etwas möglich ist.
sites/all/themes (für eigene oder zusätzliche Themes)
sites/my_site1/themes
um z.B. zwei Anzeigen zu bauen.
Kommt noch dazu, dass die Module auch in der Adminanzeige strukturiert werden. M.W. werden Module die unter den Core Modulen liegen auch im Core Fieldset ausgegeben.
Bei eigenen (selber erstellte) Modulen habe ich schon oft gesehen, dass diese auch nochmal in den Unterordner sites/all/modules/custom/modulname geschrieben werden, so hat man eine noch bessere Übersicht über die Modulstruktur.
Übrigens: die Ordner müssen noch angelegt werden.
Themes: sites/all/themes/deinTheme
Module: sites/all/modules/deineZusatzmodule
Ich hoffe dass ich es richtig erklärt habe, schöne Grüsse
Fredi
Danke Fredi! Ja das hast Du
am 06.06.2009 - 10:23 Uhr
Danke Fredi!
Ja das hast Du gut erklärt.:-)
Der Hinweis kommt gerade richtig, da bei uns mittelfristig so ein Multi-Site-Projekt ansteht.
Noch eine Frage...
Kann ich das bei bestehenden Sites so belassen oder muss ich alles umstrukturieren?
Falls ich ändern muss wie gehe ich am besten vor?
Struktur der Module...
am 06.06.2009 - 11:29 Uhr
Hallo ahoek,
wenn alles sauber läuft würde ich es belassen.
Bin auch noch eher Anfänger in gewissen Bereichen, wage aber zu behaupten dass es Drupal ziemlich egal ist wo ein Modul liegt, aber ich würde keine Änderungen mehr machen, wenn alles i.o. ist. Wo das Modul liegt mag nicht so stören, aber wie Drupal auf verschieben der Module reagiert??
Jedenfalls ohne Sicherung...ein schlechter Weg.
Trotzdem ist es halt schön eine saubere Struktur zu haben, ich würde das halt ab jetzt ändern.
Gruss aus der Schweiz
Fredi
P.S. vielleicht kann das jemand erfahrener noch etwas genauer erläutern.
ein Versuch wäre es ev. wert...
am 06.06.2009 - 11:43 Uhr
Hallo zusammen,
ich würde vielleicht mal versuchen einfach für einen kurzen Test die .htaccess umzubenennen (ohne "." vor dem Namen), falls es darin ungünstige Angaben hätte.
Bei mir hat das Devel Modul öfter auch ähnliche Probleme verursacht, vor allem wenn mehrere Optionen aktiv sind.
Da gäbe es noch einige Kandidaten. Schlimmer wäre es, wenn wichtige PHP Funktionalitäten deaktiviert wurden, dann hast du z.B. nur noch auf über den "wwwrun"-User Zugriff und Drupal (auch vieles andere) schmiert ab.
Übrigens verwende ich auch 64MB, local habe ich sogar 128MB eingestellt, da auch 64MB oft nicht mehr reichten, wenn auch Developer Tools laufen...
So jetzt aber, nochmal ein Gruss :-)
Fredi