WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: astricia on September 18, 2019, 09:53:46 AM
-
Hallo zusammen,
sorry, wenn ich mit ähnlichen Problemen immer wieder komme.... ich bin halt gerade dabei, ältere Kunden-Websites upzudaten und immer gibt es mit der Foldergallery Probleme...
Schaut mal bitte hier:
https://www.holz-aus-meck-pomm.de/pages/galerie.php
Der Aufruf der Galerie bricht ab, die Seite bleibt hier weiß. Im Backend ebenso.
Ich habe wie beim letzten Update vorab eine Kopie der alten Website auf meinen eigenen Server gezogen, das Upgrade dort ausgeführt, mögliche Ungereimtheiten beseitigt, dann wieder eine Kopie gemacht und das ganze auf den Server des Kunden hochgeladen. Bei mir sah alles einwandfrei aus, siehe hier:
http://holz-aus-meck-pomm.netschmiede24.de/pages/galerie.php
Beide Links sind WB 2.12.2 - Foldergallery 3.0.14 - PHP 7.2
Und auch noch beide Domains bei dem gleichen Hosting-Provider (All-Inkl).
Woran kann es liegen, dass die Galerie bei meiner Seite funktioniert - bei der Kundenseite aber nicht?
Sie funktionierte beim Kunden übrigens auch vorher nicht (war da noch PHP 5.6, WB 2.8.3sp7 mit FG 1.34 oder so...). Auch da blieb die Seite weiß. Ob sie bei mir auch weiß blieb, habe ich nicht getestet... aber nach dem Upgrade bei mir war sie da, brauchte halt nur noch etwas Styling. Deswegen bin ich davon ausgegangen, dass sie dann beim Hochladen auf die Kunden-Domain ebenfalls funktioniert. Tut sie aber nicht... Der Rest der Website sieht so aus, wie gewünscht/gehabt, es geht mir hier also ausschließlich um die Foldergallery.
Danke und lg,
Astrid
-
Moment.... da scheint noch mehr im Argen zu sein. Im Backend dieser Website (auf dem Kunden-Server) werden ALLE Seiten abgebrochen! Auch diejenigen, die nur ein WYSIWIG-Feld haben.
Der Seiten-Abbruch erfolgt nach folgendem Code:
<form id="wysiwyg15" action="https://www.holz-aus-meck-pomm.de/modules/wysiwyg/save.php" method="post">
<input type="hidden" name="page_id" value="11" />
<input type="hidden" name="section_id" value="15" />
<input type="hidden" name="inputSection" value="1" />
<input type="hidden" name="eb772098ca18e1ff" value="HSr8F26iXw7G2408p_fvDQ" title="">
Danach käme - im Quellcode meiner eigenen Seite im Backend zu sehen, Code, der so aussieht wie:
<textarea id="content15" name="content15" rows="8" cols="60">
Der wird aber schon nicht mehr angezeigt.
Das geht so natürlich gar nicht.... Hilfe bitte? :|
-
Lass dir die Websonsole anzeigen, Der Abbruch wird meistens durch einen Javascript Fehler verursacht.
SyntaxError: '' string literal contains an unescaped line break galerie.php:63:73
Dietmar
-
Bins nochmal, wechsel mal die jQuery Version auf 3.3.1
Dietmar
-
Noch ein Hinweis - es muss sich um zwei verschiedene Probleme handeln. Die Foldergallery war auch auf der alten Seite (WB 2.8.3 sp7, PHP 5.6, FG 1.34) im Frontend weiß. Im Backend waren aber alle Seiten editierbar - auch die Foldergallery! Ich habe die alte Seite noch mal rekonstruiert auf http://alt.holz-aus-meck-pomm.de/pages/galerie.php
Bei dem Backend-Problem der neuen Seite sind jeweils "Einstellungen ändern" und "Abschnitte verwalten" problemlos aufrufbar. Nur bei "Seite ändern" bricht die Ausgabe der Seite an der oben beschriebenen Stelle ab.
- Edit: Überschnitten. Den Fehler mit dem Zeilenumbruch habe ich behoben (stammte aus dem Google Analytics Code). Das war es aber nicht, die Probleme bleiben bestehen.
-
Bins nochmal, wechsel mal die jQuery Version auf 3.3.1
Dietmar
Erledigt. Das ändert wieder nichts an beiden Problemen.
-
Bins nochmal, wechsel mal die jQuery Version auf 3.3.1
Dietmar
Versuch macht klug, hatte da auch schon öfter Probleme, nach Wechsel lief alles
Dietmar
-
Ok, Post haben sich überschnitten.
Dietmar
-
Evtl mal den Google Analytics Code entfernen. Kann jetzt nur vermuten. Habe bislang noch keine Probleme mit der FG gehabt, benutze aber auch kein Google Analytics Code oder ähnlich.
Dietmar
-
Evtl mal den Google Analytics Code entfernen. Kann jetzt nur vermuten. Habe bislang noch keine Probleme mit der FG gehabt, benutze aber auch kein Google Analytics Code oder ähnlich.
Dietmar
Auch erledigt. Ändert wieder nichts... ich nutze den auf zig Seiten, hat noch nie ein Problem verursacht.
-
Mir ist gerade aufgefallen dass jQuery 2 mal geladen wird, einmal durch den Core und zweitens durch das Template
<script type="text/javascript" src="https://www.holz-aus-meck-pomm.de/templates/holz-aus-meck-pomm/engine1/jquery.js"></script>
Diese Zeile entfernen. Wir können uns nur langsam vortasten. Ich würde auch den DocType im Template auf html5 ändern. Die Add-ons machen reichlich Gebrauch davon (CSS3)
Dietmar
-
Ist beides erledigt. Ändert leider immer noch nichts.
Das Merkwürdige ist ja, dass es auf http://holz-aus-meck-pomm.netschmiede24.de einwandfrei funktioniert. Und die Version auf der eigentlichen Kundenseite ist ja nur eine Kopie!
-
Ist beides erledigt. Ändert leider immer noch nichts.
Das Merkwürdige ist ja, dass es auf http://holz-aus-meck-pomm.netschmiede24.de einwandfrei funktioniert. Und die Version auf der eigentlichen Kundenseite ist ja nur eine Kopie!
Wollte schauen aber
The requested URL / was not found on this server.
Dietmar
-
Hatte nen Tippfehler... habs noch geändert, klick noch mal.
-
Das Erste was mir aufgefallen ist es ist ein HTNL5 Template.
Dietmar
-
Habe Netzwerkanalyse gemacht.
Ergebnis 500 Internal Server Error auf der galerie.php
Dietmar
-
Danach käme - im Quellcode meiner eigenen Seite im Backend zu sehen, Code, der so aussieht wie:
<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
(https://i.gyazo.com/bb5db7016df425764512ea05488a9832.png)
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.
-
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
-
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
(https://i.gyazo.com/0ce2fed424409b6e54e023c290d9fd6f.png)
-
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???
-
@Helferlein
"Damals war es :-D":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
-
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
-
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
-
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
-
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...
-
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?
-
Das Backup hattest du Datei für Datei oder per Zip hochgeladen?
Zip würde Übertragungsfehler ausschließen.
-
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
-
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???
(https://i.gyazo.com/a302f145c23318333eadf1a0ba9d1ce2.png)
-
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
-
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....
-
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 :-D Aber die Haltung demotiviert.
MfG. Evaki
-
Meines Wissens hat außer dir niemand diese 500er Error bestätigen können.
So nicht richtig
im anderen Thread (https://forum.WebsiteBaker.org/index.php/topic,31579.0.html) 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?
-
@jakobi22
Wobei ich mich aktuell auf www . holz-aus-meck-pomm.de/pages/galerie.php beziehe.
Luisehahne hat den 500er hiermit (https://forum.WebsiteBaker.org/index.php/topic,31588.msg221128.html#msg221128) 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.
-
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. :roll:
Danke jedenfalls euch allen für die Hilfe, der Fall ist jetzt für mich abgeschlossen. :-D
-
Luisehahne hat den 500er hiermit (https://forum.WebsiteBaker.org/index.php/topic,31588.msg221128.html#msg221128) 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
-
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 :-D 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
-
@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 :lol: Bin übrigens auch des Programmierens (php) nicht mächtig, aber hier geht's ja um "auf Augenhöhe" miteinander.
MfG. Evaki