Foldergallery 3.0.14 - mal wieder weiße Seite

[evaki]

@jacobi22

aber nicht im Browser, dort hatte ich keinen Inhalt

Die Browser haben eine "eigene" Lesart, weshalb sie ihn nicht unbedingt auslösen bzw. anzeigen müssen - wäre bei einem 500 = dauerhaftem Ausfall natürlich etwas anders gelagert. Hier liegt tatsächlich der Schwerpunkt auf "dauerhaft".

Generell stellt sich aber hier die Frage, warum man überhaupt einen 500er auslösen kann.
Theoretisch wäre es mit php möglich. Praktisch tut's das anscheinend, aber die konkrete Situation kennen wir nicht. Ich sag's mal so. Ein kaputtes Script sollte es nicht können, wenn es das im korrekten Zustand auch nicht könnte. Aber da ist der oder sind die Programmierer gefragt.

Die andere Frage zur Fehlerbehandlung im Server stellt sich konkret wohl erst, wenn man genaueres zu den Scripten weiß. Aber da muß ich mich als Laie heraushalten, wenn ich nicht zufällig etwas "sicheres" dazu sagen kann.

astricia: ...ist aber wirklich niemals so von mir gemeint.

Ich war nur etwas genervt, - aber nun ist ja hoffentlich alles wieder gut, weiß Bescheid, und bin nicht mehr vorlaut  Bin übrigens auch des Programmierens (php) nicht mächtig, aber hier geht's ja um "auf Augenhöhe" miteinander.

MfG. Evaki

[astricia]

Akzeptiere mal, daß es hier Leute existieren, die zwar durchaus auch Fehler machen können, aber ansonsten professionell arbeiten. Du machst Dir durch Ignoranz nicht unbedingt Freunde. Wenn Du keine brauchst - auch gut  Aber die Haltung demotiviert.
MfG. Evaki

Das ist niemals Ignoranz - ich kann dir nur oft nicht folgen, weil ich die Probleme einfach nicht verstehe. Ich bin kein Programmierer, ich kann mit vielen Begriffen, mit denen du so hantierst, nichts anfangen. Dann weiß ich auch nicht, wie ich darauf antworten soll. Das kannst du natürlich als Ignoranz auslegen, ist aber wirklich niemals so von mir gemeint. Ich weiß es sehr wohl zu schätzen, dass mir hier geholfen wird, wenn ich Probleme habe und hoffe, das auch in der Vergangenheit oft genug kommuniziert zu haben.

LG,
Astrid

[Gast]

Luisehahne hat den 500er hiermit bestätigt.

@Evaki
wie wahrscheinlich ist denn ein 500er, wenn (wie ich vermute) zu diesem Zeitpunkt noch nicht alles hochgeladen wurde? z.b. Access-File: ist da, view.php und/oder JS-Dateien für die FG und/oder WB noch nicht?
Den 500er hatte ich ja auch nur mit Tools wie Netzwerkcheck, Validator usw, aber nicht im Browser, dort hatte ich keinen Inhalt

[astricia]

Code Select Expand

Wie ist denn nun der Stand der Dinge?

Das Backup hattest du Datei für Datei oder per Zip hochgeladen?
Zip würde Übertragungsfehler ausschließen.

Datei für Datei ... und ja, da habt ihr wohl Recht, es waren tatsächlich Übertragungsfehler. Habe gerade einen weiteren Down- und Upload über ZIP (über das All-Inkl Web-FTP) hinter mir. Was soll ich sagen..... es funktioniert jetzt.

OK, also ich merke mir, dass ich solche Dinge demnächst nur noch über ZIP und am besten über ein Web-FTP des jeweiligen Hosters mache. Menno... das ist mir in all den Jahren vorher nie passiert, das beim Down-/Upload irgendwas falsch übertragen wurde und jetzt gleich zwei Wochen hintereinander. 

Danke jedenfalls euch allen für die Hilfe, der Fall ist jetzt für mich abgeschlossen.

[evaki]

@jakobi22
Wobei ich mich aktuell auf www . holz-aus-meck-pomm.de/pages/galerie.php beziehe.
Luisehahne hat den 500er hiermit bestätigt.

Anscheinend funktioniert die Seite jetzt, womit eine Erklärung für alle wohl hilfreich sein könnte.
Oder wollen wir jedesmal von vorne anfangen und dennoch keinen Erkenntnisgewinn bekommen?
MfG. Evaki
Nachtrag wg Überschneidung: Scheint ja zu laufen. Tests führe ich aber keine durch, da die FG ja anscheinend sonstwo bisher ohne Beanstandungen funktioniert.

[Gast]

Meines Wissens hat außer dir niemand diese 500er Error bestätigen können.

So nicht richtig

im anderen Thread schrieb ich:

den 500er Fehler habe ich nur unter Verwendung von Tools auf der Seite, die vorher nicht ging, also der neu-Domain. Das sollte mittlerweile aber erledigt sein

nach Erklärung deiner Arbeitsschritte, z.B. Überschreibung bzw Löschen des alten Paketes zu diesem Zeitpunkt gehe ich aber davon aus, das zumindest mein 500er eher das Produkt eines unglücklichen Zeitpunktes war, wo Teile des Paketes schon auf dem Server waren und andere noch nicht.
Und da wir (Evaki und ich) ja recht zeitgleich zu Gange waren, könnte es dort der gleiche Auslöser gewesen sein. Sehe ich als nicht so dramatisch an, wenn man weiß, das du zu diesem Zeitpunkt daran gearbeitet hast.

Wie ist denn nun der Stand der Dinge?

[evaki]

Es gibt keine örtlichen Störungen mehr.
500er ist auch bestätigt von "Luisehahne"
Auch wurde darauf hingewiesen, was konkret durch die Störung eingeschränkt wurde - inkl. Folgen.

Ich traue der hiesigen Firma mit ihren Werkzeugen mehr als Deinen Aussagen, die wiederholt am Problem vorbei reden.

Akzeptiere mal, daß es hier Leute existieren, die zwar durchaus auch Fehler machen können, aber ansonsten professionell arbeiten. Du machst Dir durch Ignoranz nicht unbedingt Freunde. Wenn Du keine brauchst - auch gut  Aber die Haltung demotiviert.
MfG. Evaki

[astricia]

Beispielsweise aus der Ferne einen 500er error auslösen zu können, ist jedenfalls nicht zulässig, genauer "ein schwerwiegender Fehler". 

Meines Wissens hat außer dir niemand diese 500er Error bestätigen können. Und du hast letzte Woche selbst gesagt, dass du Telekom-Probleme hattest, als dies auftrat. Ich sehe das Problem daher eher bei dir als bei den Servern meiner Kunden, sorry....

[Gast]

Zuerst falsches Paket hochgeladen ..... Das habe ich zwar auf dem Server gelöscht, bevor ich (in das gleiche Verzeichnis) das richtige Backup hochgeladen habe, aber irgendwas ist da beim FTP-Upload schief gelaufen.

nur mal als Information bzw auch als Frage von mir:
andere Kunden bei anderen Anbietern haben in ihren AdminPanels ein Setting, das sich meist "Cache-Manager" nennt. Hintergrund sind schnellere Ladezeiten der Seiten. Hab grad bei einer Kundin geschaut, da steht diese Cache-Zeit auf 4 Stunden, weiter möglich sind: kein Cache, 1 Stunde, 12 Stunden, 24 Stunden.
Funktionsweise in etwa: ich lade eine Datei hoch, diese wird nach dem Erfassen für die eingestellte Zeit blockiert und in den Cache geladen. Erst nach Ablauf der eingestellten Zeit wird nach einer neuen Version dieser Datei geschaut. Das macht den Browser wohl recht schnell, behindert mich aber in der Wartung, z.b. als die Reparatur eines Modul einfach nicht übernommen wurde.

Lt Web verwendet AllInkl wohl eine ähnliche Lösung über das PHP-Modul mod_expires in Verbindung mit einer .htaccess im Rootverzeichnis. Bei AllInkl selbst finde ich dazu bisher aber keine Informationen. mod_expires bewegt die Browser dazu, Dateien, die bereits im Browserspeicher sind, nicht noch einmal neu zu laden. Im Falle solchen Updates natürlich eher hinderlich. Entweder, man nutzt dann mehrere Browser oder man leert ständig die Cache's der Browser.

Ob das auch für dieses Problem zutrifft, kann ich nicht sagen

[Gast]

Bei "all-inkl" würde ich mal die Helferlein vom Hoster nutzen.
Also ein zip-File über den Web-FTP-Client von der funktionierenden Seite erstellen lassen.

Ich sehe im KAS von all-inkl keinen Web-FTP-Client, wo soll der sein???

[evaki]

habe ZWEI Fehler auf dieser Seite.

Ja, aber die Ursache kann dennoch exklusiv eine sein, als Fehler und Folgefehler.
Beispielsweise aus der Ferne einen 500er error auslösen zu können, ist jedenfalls nicht zulässig, genauer "ein schwerwiegender Fehler". 

Wie wiederholt erwähnt, wäre es sinnvoll den Hoster zu kontaktieren, um etwas über evtl. aktive Schutzmaßnamen auf dem Server zu erfahren, damit man z.B. weiß in welchem Falle wie und wo die greifen, und was - wenn er's weiß - der Auslöser sein könnte/ist. Gegebenenfalls hängen davon u.U. auch Änderungen am Modul ab.

Bezeichnend ist in diesem Zusammenhang auch

Dieser Fehler trat auf diesem Server bereits bei der 2.8.3sp7 auf.

Mal abgesehen von FG als Auslöser/Fehlerquelle:
Die Server können recht unterschiedlich auf Fehler reagieren, oft unterschiedlich auf www oder Subdomain.

MfG. Evaki

[dbs]

Das Backup hattest du Datei für Datei oder per Zip hochgeladen?
Zip würde Übertragungsfehler ausschließen.

[astricia]

Also bei einem Fresh Install kann ich im Backend zumindest schon mal einen WYSIWIG-Editor sehen. Module und Templates installieren und Media-Ordner hochladen hat auch funktioniert.

Aber wie kann ich nach dem Hochladen des Pages-Ordner (per FTP) die Datenbank so synchronisieren, dass es die Dateien auch erkennt? Gibts da nen Trick?

[astricia]

zumal - soweit ich weiß - nicht erklärt wurde, warum der Fehler auf der neuen Site verschwunden ist.

wenn ich das richtig gelesen habe, wurde zuerst ein falsches Paket hochgeladen. Da sich die Anfangsprobleme auf die FG in Front- und Backend bezogen, vermute ich, es war ein Paket ohne diese FG

Zuerst falsches Paket hochgeladen und das richtige dann "drüber geladen" war das Problem bei dem Projekt letzte Woche (Karina). Es war nicht ein Paket ohne FG - sondern zuerst das alte Backup (von der 2.8.3). Das habe ich zwar auf dem Server gelöscht, bevor ich (in das gleiche Verzeichnis) das richtige Backup hochgeladen habe, aber irgendwas ist da beim FTP-Upload schief gelaufen. Dieses Problem habe ich dieses Mal NICHT gehabt!

Es liegt also der Verdacht nahe, daß sich im Ablauf etwas wiederholt - was immer das auch sein mag.

100% conform

Nein, auch wenn es sich ähnlich anhört, die Problemursache muss eine andere sein. Wie gesagt - ich habe ZWEI Fehler auf dieser Seite.

Das Schwerwiegendere ist, dass im Backend keine WYSIWYG- und FG-Abschnitte editierbar sind. Die Seite bleibt weiß, bricht ab.

Der andere Fehler ist, dass die Folder-Gallery auch im Frontend nicht angezeigt wird. Dieser Fehler trat auf diesem Server bereits bei der 2.8.3sp7 auf. Beim Installieren auf meiner Testsubdomain tritt dieser Fehler nicht auf.

Mein nächster Versuch ist es jetzt, WB 2.12.2 komplett neu zu installieren und dann die entsprechenden Module, das Template sowie den Pages- und Media-Ordner einzubauen. Mal sehen, ob das funktioniert...

[astricia]

Bei "all-inkl" würde ich mal die Helferlein vom Hoster nutzen.
Also ein zip-File über den Web-FTP-Client von der funktionierenden Seite erstellen lassen.

Ich sehe im KAS von all-inkl keinen Web-FTP-Client, wo soll der sein???

LG,
Astrid

[Gast]

zumal - soweit ich weiß - nicht erklärt wurde, warum der Fehler auf der neuen Site verschwunden ist.

wenn ich das richtig gelesen habe, wurde zuerst ein falsches Paket hochgeladen. Da sich die Anfangsprobleme auf die FG in Front- und Backend bezogen, vermute ich, es war ein Paket ohne diese FG

Es liegt also der Verdacht nahe, daß sich im Ablauf etwas wiederholt - was immer das auch sein mag.

100% conform

[hgs]

Bei "all-inkl" würde ich mal die Helferlein vom Hoster nutzen.
Also ein zip-File über den Web-FTP-Client von der funktionierenden Seite erstellen lassen.
Diese downloden und wider per WinFTP-Client mit "entpacken" zurück spielen.
Damit hatte ich noch nie Probleme bei "all-inkl"
DB hin und her mache ich auch nur mit den Bordmittel von all-inkl. auch da noch nie Probleme gehabt.

Vieleicht hilft das ja

[evaki]

@Helferlein
"Damals war es  ":

das Problem mit der Groß-/Kleinschreibung hatte evaki bei seinen Fehlerberichten,

Das bezog sich auf die Subdomain, die ich im Blick hatte, und nicht auf die neue funktionierende Site.
Daher, eben weil das Phänomen dort auftrat, ist es nicht ausgeschlossen, daß sich derartiges wiederholt, zumal - soweit ich weiß - nicht erklärt wurde, warum der Fehler auf der neuen Site verschwunden ist.

Bei der jetzigen, also aktuellen anderen Domain - bei mir ist netzmäßig wieder alles in Ordnung - , habe ich eine der Testsuiten laufen lassen, wobei prompt wieder der 500er error ausgelöst werden konnte. Es liegt also der Verdacht nahe, daß sich im Ablauf etwas wiederholt - was immer das auch sein mag.

Leider habe ich momentan kein Zeitfenster, wo ich die FG "abklopfen könnte".
Daher nur die Anmerkungen.
MfG. Evaki

[astricia]

Hab ich überprüft - bei mir steht es auf "keine Veränderung". Groß- und Kleinschreibung wird also beibehalten.

Der erneute Down- und Upload ist erfolgt. Leider ohne Veränderung. Im Backend nur leere Seiten. Im Frontend bleibt die Galerie weiß.

Ich habe im Backend eine Testseite mit anderen Abschnitten angelegt - Code, Form, SectionPicker etc. ... besteht die Seite nur aus diesen, lässt sie sich problemlos aufrufen. Bei Seiten mit WYSIWIG-Editor und/oder Foldergallery (auch wenn nur eins von beiden da ist), wird die Ausgabe abgebrochen.

Wenn ich über den FTP-Client die Verzeichnisse modules/ckeditor und modules/foldergallery auf meinem lokalen Rechner und auf dem Server vergleiche, kommt "Keine Unterschiede gefunden".

Was kann es denn dann noch sein???

[Gast]

Ich nutze WinSCP als FTP-Client.

Offtopic und nur als Info, aber vielleicht braucht es ja mal wer

WinSCP ->nach Anmeldung auf Einstellung, es erscheint das linke Fenster, dort auf Übertragung (1.).
Im rechtem Teil des Fensters erscheinen die Profile, Standardeinstellung (2.) ist "binäre Übertragung"
Nach Klick auf "Bearbeiten" (3.) erscheinen die Profileinstellungen
Im gelb markierten Feld "Dateinamenanpassung" (4.) sieht man dann die Einstellung für dieses Profil.
Bei der Auswahl "Keine Veränderungen" werden keine Anpassungen gemacht, d.h. alle Dateinamen bleiben so erhalten, wie im Quellordner vorgegeben.

P.S.: wer allerdings sein unter Windows verwaltetes lokales Backup durch Überschreiben von Dateien "updatet", kann da böse Überraschungen erleben. Im besten Fall bleiben beide Dateien erhalten (jeweils mit Groß und Kleinbuchstaben am Beginn), im Worstcase behält Windows die Datei, die zuerst da war und das ist i.d.R. die ältere mit kleinem Buchstaben am Beginn

[astricia]

Hallo Uwe,

das Problem mit der Groß-/Kleinschreibung hatte evaki bei seinen Fehlerberichten, nicht ich. Ich habe gerade noch mal überprüft - auf dem Server sieht der CK-Editor identisch mit deinem Screenshot aus (ich habe noch eine README.md... ansonsten genau gleich, inklusive Groß und Kleinschreibung).

Ich vermute jetzt aber trotzdem, dass es irgendwas mit meinem FTP-Down- und Upload zu tun hat. Ich nutze WinSCP als FTP-Client. Daher starte ich gerade einen weiteren Versuch, die funktionierende Website von meinem Server herunter- und dann auf den Kundenserver in ein weiteres Verzeichnis hochzuladen. Vielleicht klappt es diesmal...

LG,
Astrid

[Gast]

Danach käme - im Quellcode meiner eigenen Seite im Backend zu sehen, Code, der so aussieht wie:

Code Select Expand

<textarea id="content15" name="content15" rows="8" cols="60">

Der wird aber schon nicht mehr angezeigt.

die Codezeile mit dem textarea stammt (schon) aus dem CKEditor. Wenn hier das Laden abgebrochen wird, wird auch der Rest nicht mehr dargestellt. Als Beispiel: ich habe eine Seite mit 2 Sectionen, oben ein Wysiwyg mit Einleitung, darunter die FG. Bricht das Wysiwyg ab, wird auch die Maske der FG nicht dargestellt.

Ich vermute, wie auch beim letzten Thread, ein Problem mit der Groß- und Kleinschreibung, hier im Speziellen im CKEditor, Verzeichnis modules/ckeditor/ckeditor
Anbei ein Screenshot dieses Ordners, hier geht es besonders um die beiden PHP-Dateien CKEditor.php und CKEditorPlus.php. Ich würde empfehlen, den gesamten Inhalt des Ordners zu löschen und aus dem WB-Paket inklusive Nachkontrolle neu hochzuladen. Gleiches gilt für den Ordner modules/foldergallery



P.S.: du bist häufig von diesen Problemen betroffen. Eine mögliche Ursache könnte neben Windows auch dein FTP-Client sein. Hier gibt es einige mit der Option "Alle Dateien mit Kleinbuchstaben" oder "Dateinamen bei Übertragung ändern", z.b. WSFTP, Wise-FTP, Total Commander usw
Bei CKEditor sind die zwei genannten eigentlich die Basis des Editors, ohne die geht garnichts und in der FG würde es schon reichen, wenn der DirectoryHandler nicht mehr angesprochen wird. Auch das eine Datei, die mit großem Buchstaben beginnt.

[Luisehahne]

Habe Netzwerkanalyse gemacht.
Ergebnis 500 Internal Server Error auf der galerie.php

Dietmar

[Luisehahne]

Das Erste was mir aufgefallen ist es ist ein HTNL5 Template.

Dietmar

[astricia]

Hatte nen Tippfehler... habs noch geändert, klick noch mal.