WebsiteBaker Community Forum
WebsiteBaker Support (2.13.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: sabo-! on December 01, 2023, 09:58:24 PM
-
Hallo,
nach dem letzten Update lassen sich keine Bilder mehr einfügen. Im Bereich Medien lässt sich das Bild zunächst erfolgreich hochladen und wird auch in der Vorschau angezeigt. Will man es dann in der Seite über das Bild-Einfügen-Icon einfügen, ist die Vorschau des Bildes leer und bei Einfügen erscheint stattdessen ein X mit einem WebsiteBaker-Infotext.
(https://www2.pic-upload.de/img/37317831/fehler-bild.jpg)
Im Bereich Optionen war immer schon ein mailto-Link eingefügt. Im Backend fügt das System jetzt nach dem Update vor und nach den Anführungszeichen drei Backlash ein.
<a href=\\\'mailto:info@meine-domain.de\\\'>info@meine-domain.de</a> im Frontend ist statt dem Mail-Link folgendes verlinkt: https://www.meine-domain.de/"mailto:info@meine-domain.de/" Es wird also vor dem mailto-Link die URL der Website hinzu gesetzt.
WB-Version 2.13.4 r199, PHP 8.2, Ausreichende Schreib- und Leserechte in den Ordnern media und pages sind gesetzt.
Für Hilfe wäre ich dankbar.
Grüße
Sabo
-
Hallo, das Problem mit Slashes ist bekannt und gefixt, nur leider noch nicht veröffentlicht.
Im Anhang findest du den Fix. Den Inhalt des Zips in dein Hauptverzeichnis kopieren.
Rückmeldung wäre gut.
-
Ich kann das Problem mit den Bildern nicht bestätigen. Zu den sich vermehrenden ///// hat dbs ja schon das Patch gepostet.
Ist eine WB 2.13.4 r199 mit PHP 8.2.9 als Neuinstall.
Es wird alles sauber im BE und FE angezeigt.
Bei dir wird es wahrscheinlich ein upgrade gewesen sein.
Wie hast du es gemacht?
Wir empfehlen die Methode mit unzip.php wie sie im DUKU Ordner beschrieben ist.
Siehe diese kleine Video (https://www.youtube.com/watch?v=2Vi5v7vhKx8)
https://r199.wb.umojasingers.de/ (https://r199.wb.umojasingers.de/)
Das 1. Bild habe ich gerade eingefügt.
(https://gyazo.com/e794c49c08a06154c500dc13f22f1ed8.png)
https://gyazo.com/e794c49c08a06154c500dc13f22f1ed8 (https://gyazo.com/e794c49c08a06154c500dc13f22f1ed8)
-
Stehe wohl schon auf der Liste der Geächteten, weil ich immer nur meckern muß.... :cry:
@hgs: das Ganze ist abhängig von den einzelnen Dateien, die gerade auf dem Server sind. Beim Einfügeproblem mit dem Bildern ist es so, das der Pfad zur config.php des CKEditors nicht mehr stimmt, weil auch da diverse Backslashes drin sind. Zum besserem Verständnis nimm dir mal die Zeit, entpacke die letzten 3 oder 4 Hauptversionen (WB 2.11, WB 2.12 usw) in jeweils einen separaten Ordner und suche dann ordnerweise nach 2 Backslashes, also \\ oder auch nach dreien solcher Backslashes und du wirst erschrocken sein, wie sich das Problem über die Hauptversionen aufgebaut hat. Und so findet der CKEditor seine config.php nicht und das Accordion-Modul (bzw. jedes andere Addon, das auch die Translate-class nutzt), eben den modul-internen Pfad nicht mehr, der zu den languages-Dateien führt.
Ergebnis sind dann Pfade, die auf dem Server nicht mehr gefunden werden. Der Patch korrigiert einige davon, die Wichtigsten.
Zum Mail-Adress-Problem: innerhalb von WB wird jeder POST-Auftrag, also das Senden von Daten zum z.b. Speichern durch eine Funktion abgesichert, die diese Daten vor dem Abspeichern in die DB entsprechend behandelt. Der spezielle Link
<a href='mailto:info@meine-domain.de'>info@meine-domain.de</a>
enthält Hochkommas, rot markiert. Diese müssen für die Nutzung in der Datenbank "maskiert" werden, sehen in MySQL dann also so aus
<a href=\'mailto:info@meine-domain.de\'>info@meine-domain.de</a>
Nun hat sich mit PHP8 der Fehler eingeschlichen, das diese Daten zweimal maskiert werden, was zur Folge hat, das nun auch der in der DB vorhandene Backslash vor dem Hochkomma mit zwei weiteren Backslashes "maskiert" wird. Und mit jedem Mal Speichern, werden es immer mehr und schaut nach 7 x Speichern dann so aus
(https://i.gyazo.com/05d08d9e1c3acba488cef7b0db072e89.png)
Betroffen sind alle Textfelder, die zum Speichern wb-interne Funktionen benutzen, z.b. $database->escapeString
Nicht betroffen sind die Textfelder des CKEditors, weil der eine eigene Routine zur Maskierung der Texte hat
Für die Ausgabe im Frontend gilt: alles, was ausgegeben wird, läuft durch den Output-Filter. Dieser ersetzt dann z.b. die {SYSVAR:AppUrl.MediaDir} oder verschlüsselt die EMail-Adressen im Text. Für letzteres sucht der Filter nach Buchstaben- bzw Zeichen-Kombinationen, hier im Speziellen nach href und mailto. Kann der Filter das dann nicht sauber erkennen und trennen, kommt genau solch Ergebnis raus wie vom User sabo-! beschrieben, also ein https://www.meine-domain.de/"mailto:info@meine-domain.de/"
Unser Hauptproblem ist, das wir mit diesem Fehler unsere ganzen Datenbanken vollschreiben mit solchen mehrfachen Backslashes, egal, ob das nun Droplets sind oder Form-Einstellungen, News oder Gästebücher. Mit der aktuellsten Testversion R213 wird wohl intern viel korrigiert und das, was man gerade behandelt, z.b. WB-Optionen) wird dann sauber gespeichert, aber es ist unklar und serverabhängig, wieviele Droplets z.b. solch Eingaben kompensieren. Solch Code
$oLang->enableAddon(\'templates\\\\\'.TEMPLATE);\nfunktioniert dann eben nicht mehr bei jedem
-
Jetzt wird einiges klar, und da ich bei einer Neuinstall getestet habe, kommt das Problem nicht auf.
Danke für die Aufklärung.
-
Rückmeldung wäre gut.
@Sabo
Hast du schon ein Feedback für uns?
-
Hallo,
ich habe das in meinem Post falsch beschrieben. Sorry. Es war kein Update, sondern ein Umzug der Website zu einem anderen Provider. Ich bin dabei so vorgegangen, wie in dieser Beschreibung: https://help.WebsiteBaker.org/en/knowledge-base/moving-from-server-a-to-b.php
Das Problem mit den Backslashes im Footer konnte durch den Fix behoben werden. Vielen Dank.
Das Problem mit den Bildern existiert jedoch weiterhin. Ich konnte herausfinden, dass alte Bilder, die bereits (vor dem Umzug) hochgeladen wurden, eingefügt werden können, jedoch keine neu hochgeladenen Bilder, die nach dem Umzug hochgeladen wurden. Da erscheint dann das beschriebene Problem.
Neu hochgeladene Bilder sind zwar im Bereich "Medien" sichtbar, lassen sich aber nicht einfügen.
Es klappt auch nicht, wenn ich Quellcode anpasse. Ich habe also das neue Bild hochgeladen und versuche alternativ in der Ansicht "Quellcode" einfach in der Bild-URL den Namen des Bildes zu ändern. Wenn ich dann wieder zurück auf den normalen Editor schalte, erscheint statt dem Bild ein "Broken-Image", also das was erscheint, wenn die Bilder-URL nicht stimmt.
Ich habe dann das Bild per FTP in das Root-Verzeichnis der Website hochgeladen und den nochmal in der Ansicht Quellcode die Bilder-URL angepasst. Das hat funktioniert. Das Bild wird angezeigt. Also img src="https://www.meine-domain.de/media/bild1.jpg ging nicht, aber img src="https://www.meine-domain.de/bild1.jpg ging.
Dann habe ich noch folgenden Test gemacht und das neue Bild per FTP in das Medienverzeichnis hochgeladen und konnte es dann erfolgreich ganz normal über das Bild-Einfügen-Icon in die Seite einfügen.
Es muss also mit dem Hochladen der Bilder in der Medien Verwaltung zu tun haben.
-
Also img src="https://www.meine-domain.de/media/bild1.jpg ging nicht, aber img src="https://www.meine-domain.de/bild1.jpg ging.
Bitte in Schritt 1 die WB_URL in der config.php dieser Installation kontrollieren. Hat sie ggf ein Slash am Ende? Wenn JA, unbedingt entfernen
In Schritt 2 bitte in die erweiterten WB-Optionen und dort in den Abschnitt SERVER. Ist dort das /media-Verzeichnis eingetragen und grau hinterlegt, also nicht beschreibbar?
Diese Einstellung würde ich auch direkt in der Datenbank gegenchecken, Tabelle settings, Feld: media_directory
(https://i.gyazo.com/6361d59c7c326130a34b56a8fc8cc0f5.png)
Schritt 3: Ist eine .htaccess im Einsatz? Falls JA, bitte mal durch Umbenennen oder Verschieben in einen neu angelegten Ordner deaktivieren.
Schritt 4: Füge bitte mal nach beiden von dir beschriebenen Methoden (mein Zitat oben) je ein Bild ein. Lt deiner Beschreibung hast du dann ein nicht funktionierendes Bild und eines, das du sehen kannst. Speichere diese Section und kontrolliere im Anschluß direkt in der Datenbank in Tabelle mod_wysiwyg den dort gespeicherten Quellcode für diese Section. Mindestens ein Eintrag sollte so aussehen
img src="{SYSVAR:AppUrl.MediaDir}bild1.jpg
Bitte mal beschreiben, was da exakt für beide Bilder gespeichert wird
Es klappt auch nicht, wenn ich Quellcode anpasse. Ich habe also das neue Bild hochgeladen und versuche alternativ in der Ansicht "Quellcode" einfach in der Bild-URL den Namen des Bildes zu ändern. Wenn ich dann wieder zurück auf den normalen Editor schalte, erscheint statt dem Bild ein "Broken-Image", also das was erscheint, wenn die Bilder-URL nicht stimmt.
Interessant wäre, zu wissen, was denn als URL im Quellcode angezeigt wird, wenn du nach dem Erscheinen des Broken Image im Editor erneut auf Quellcode umschaltest.
Aktuell bin ich eher bei einer serverseitigen Problematik, z.b. einer server-interne Umleitung, wie man sie bei Subdomains findet. Eventuell auch bei einer "falschen" WB_URL, einem URL-Rewrite auf Grund von Servereinstellungen und/oder einer .htaccess
Beschränkt sich das Problem ausschließlich auf den CKEditor, könnte man zur Prüfung mal ein paar der dort verarbeiteten URL's ausgeben lassen. Aber schauen wir erstmal, was hier rauskommt.
-
Bitte in Schritt 1 die WB_URL in der config.php dieser Installation kontrollieren. Hat sie ggf ein Slash am Ende?
-> Kein Backslash
In Schritt 2 bitte in die erweiterten WB-Optionen und dort in den Abschnitt SERVER. Ist dort das /media-Verzeichnis eingetragen und grau hinterlegt, also nicht beschreibbar?
-> /media-Verzeichnis ist eingetragen und grau hinterlegt
Schritt 3: Ist eine .htaccess im Einsatz? Falls JA, bitte mal durch Umbenennen oder Verschieben in einen neu angelegten Ordner deaktivieren.
-> keine .htaccess vorhanden
Schritt 4: Füge bitte mal nach beiden von dir beschriebenen Methoden (mein Zitat oben) je ein Bild ein. Lt deiner Beschreibung hast du dann ein nicht funktionierendes Bild und eines, das du sehen kannst. Speichere diese Section und kontrolliere im Anschluß direkt in der Datenbank in Tabelle mod_wysiwyg den dort gespeicherten Quellcode für diese Section.
-> Im Editor und Seitenquellcode ist die Bild-URL: src="https://www.meine-domain.de/media/bild1.jpg"
In der Datenbank so: src="{SYSVAR:AppUrl.MediaDir}bild1.jpg"
Interessant wäre, zu wissen, was denn als URL im Quellcode angezeigt wird, wenn du nach dem Erscheinen des Broken Image im Editor erneut auf Quellcode umschaltest.
-> Da ändert sich nichts. Die Bild-URL meine-domain.de/media/bild... bleibt unverändert.
-
Vielen Dank für deine Geduld und Mitarbeit (Y)
Interessant wäre, zu wissen, was denn als URL im Quellcode angezeigt wird, wenn du nach dem Erscheinen des Broken Image im Editor erneut auf Quellcode umschaltest.
-> Da ändert sich nichts. Die Bild-URL meine-domain.de/media/bild... bleibt unverändert.
Das Problem ist wohl, das es derzeit niemand nachstellen kann, von daher ist das eher ein Ratespiel :|
Mal zur Technik: das Bild noimage.png (rotes Viereck mit grauem Kreuz / dein Eingangs-Post) im Bilderdialog des CKEditors erscheint, wenn die im Feld "textInput" angezeigte URL zu einem Bild nicht valide ist, das dort angezeigte Bild also nicht geöffnet werden kann.
Der CKEditor-interne Filebrowser, der ja bei dir funktioniert, nutzt die WB_URL plus den Eintrag aus der settings-Tabelle zu media_dir (also media) als Startverzeichnis und hängt da noch einen Slash heran. An diese Kombination wird dann der angewählte Bildname angehängt und so entsteht die Bild-URL im Bilder-Dialog-Fenster. Ist sie einmal drin und das Bild wurde angezeigt, ist sie also valide und der Filebrowser hatte auch die Berechtigung zum lesen des Bildes.
Nun kommt ein weiteres Script und liest die URL erneut und bekommt einen Fehler
Ich les nochmal nach:
Das Problem mit den Bildern existiert jedoch weiterhin. Ich konnte herausfinden, dass alte Bilder, die bereits (vor dem Umzug) hochgeladen wurden, eingefügt werden können, jedoch keine neu hochgeladenen Bilder, die nach dem Umzug hochgeladen wurden. Da erscheint dann das beschriebene Problem.
Neu hochgeladene Bilder sind zwar im Bereich "Medien" sichtbar, lassen sich aber nicht einfügen.
Kann es sein, das deine Dateirechte nicht passen? Und war da nicht schon etwas an anderer Stelle?
Bitte mal kontrollieren im FTP-Programm im Ordner /media und bei einem Bild, das vorher schon da war und im CKEditor funktioniert und eines, das neu hochgeladen wurde und nicht funktioniert.
Bei mir in WIN_SCP mit rechter Maustaste auf ein Bild, dann Eigenschaften. Wichtig sind Eigentümer, Gruppe und der Oktalwert
(https://i.gyazo.com/e5b69384e3b11fd9b9ad2b10ae8b854d.png)
-
Das Bild noimage.png (rotes Viereck mit grauem Kreuz) im Bilderdialog des CKEditors erscheint.
Die Rechte der Dateien im Ordner /media sind alle: rwxrwxr-x
Das Bild, das per FTP hochgeladen wurde hat: rw-r--r--
Das Bild, das über die Upload-Funktion im Bereich "Medien" hochgeladen wurde und nicht angezeigt wird, hat: rw-r-----
-
Das Bild, das über die Upload-Funktion im Bereich "Medien" hochgeladen wurde und nicht angezeigt wird, hat: rw-r-----
*autsch
Wie schaut es denn in den erweiterten WB-Optionen aus bei den Rechten? Und dann dazu die Rechte, wie sie das FTP-Programm anzeigt.
(https://i.gyazo.com/38cf1da52b702fa2b46a602c77c1a558.png)
Hab so den Verdacht, das du nicht unbedingt der User mit den vollen Rechten bist auf deinem Server, die Meldung der Datenbank aus dem anderen Thread würde dazu passen
-
In den WB-Optionen ist bei mir im Bereich "Dateien": 0640 rw-r-----
Und im Bereich "Verzeichnisse": 0750 rwxr-x---
Mit FTP kann ich sehen, dass der Ordner /media diese Rechte hat: rwxrwxr-x
-
Habt Ihr noch Tipps, wie ich in der Sache mit den Bild-Problemen zu einer Lösung kommen kann?
-
Wenn ich mich nicht irre, sollten
Dateien mit dem Recht 0644 (rw-r--r--)
und Verzeichnisse mit dem Recht 0755 (rwxr-xr-x)
funktionieren,
ist das so bei dir eingestellt?
Alternativ kannst du einem von uns die BE Zugangsdaten vom SuperAdmin und die FTP-Zugangsdaten per pm zukommen lassen, dann würden wir mal drüberschauen
-
Ich habe die Rechte des Verzeichnisses angepasst. Wenn ich danach ein Bild neu hochlade, setzt das System die Rechte dieses Bildes auf rw-r-----
Lässt sich daraus eine mögliche Lösung einschätzen?
-
Das kann ich gar nicht sagen, dass hört sich so an, als wenn der Server eine "falsche Grundeinstellung" hat.
Mittlerweile gibt es die nächste Version von WebsiteBaker, siehe oben rechts "Neuigkeiten"
Published WebsiteBaker 2.13.5 R220
2023-12-21 : download on wiki… (https://wiki.WebsiteBaker.org/doku.php/en/downloads)
Das behebt die Probleme mit den wachsenden \\\\\ und im Bereich Footer und Header ist der Button "Server durchsuchen" zum Bilder einfügen jetzt vorhanden.
Das wäre mal ein nächster Versuch. Die zu vielen \\\\\ werden nach "speichern" automatisch entfern
-
Ich habe herausgefunden, dass das Problem mit den hochgeladenen Bildern bei ALLEN Websites besteht, die kürzlich von mir auf Eurer Anraten hin umgezogen sind, weil WebsiteBaker künftig Host Europe als Provider nicht supporten wird.
Ich werde das mit dem neuen Update in den nächsten Tagen bei einer dieser Website testen.
-
Welchen neuen Provider hast du jetzt?
-
Alle betroffenen Seiten sind bei all-inkl.com.
-
Ich habe jetzt auf einer der Seiten das Update installiert. Das Problem besteht immer noch. Im Quellcode ist das Bild in der Seite drin, wird aber nicht angezeigt. Alle Bilder, die über den Upload-Button hochgeladen werden, erhalten vom System die Rechte rw-r----- (0640).
-
Alle betroffenen Seiten sind bei all-inkl.com.
Da habe ich auch alle meine Domänen und den Testbereich für WebsiteBaker. Das ist sehr komisch.
-
Das Bild, das über die Upload-Funktion im Bereich "Medien" hochgeladen wurde und nicht angezeigt wird, hat: rw-r-----
*autsch
Wie schaut es denn in den erweiterten WB-Optionen aus bei den Rechten? Und dann dazu die Rechte, wie sie das FTP-Programm anzeigt.
(https://i.gyazo.com/38cf1da52b702fa2b46a602c77c1a558.png)
Hab so den Verdacht, das du nicht unbedingt der User mit den vollen Rechten bist auf deinem Server, die Meldung der Datenbank aus dem anderen Thread würde dazu passen
Wie sieht diese Einstellung bei dir aus?
-
Wie schon oben geschrieben steht bei mir an dieser Stelle:
Dateien: 0640 / rw-r-----
Verzeichnisse: 0750 / rwxr-x---
-
Hallo,
da scheint wohl beim Umzug was schiefgelaufen zu sein. Die Dateirechte sollten bei 644 die Verzeichnisrechte bei 755 sein. Allinkl hat einen sehr guten Support. Ruf bei denen an und schildere dein Problem. Bitte sie die Datei- und Verzeichnisrechte (chmod) entsprechend einzustellen (rekursiv, so dass auch alle Unterordner eingeschlossen sind). Lass in dem Zusammenhang auch gleich überprüfen, ob du als Dateieigentümer (chown) eingetragen bist. Wenn ich dich richtig verstanden habe, kannst du die Einstellungen für "alte" Dateien ändern, bez. sind dies richtig, nur neu hochgeladene (über php scripte vom WB Backend) bekommen falsche Rechte. Scheint für mich drauf hinzudeuten, dass es sich um eine Problem der Serverkonfiguration zu handeln. Da hast du eh keinen Zugriff drauf. Das muss sich der Support von Allinkl anschauen.
Frohe Weihnachten
-
Hallo,
Nachtrag: Ich hab grad bei meinen allinkl Installationen nachgeschaut. Bilder die ich über die Media Verwaltung von WebsiteBaker in das media Verzeichnis hochlade haben bei mir auch die Dateirechte 644. Ich kann die Bilder aber ohne Probleme in der Mediaverwaltung sehen und diese auch in meine Seiten einbinden. Mein Server verhält sich mir Rechtevergabe genau so, wie du es in deinen Posts beschrieben hast.
Als langjähriger (mehrere Jahrzehnte) Kunde von allinkl, mit denen ich diverse Domänumzüge durchgezogen habe, schließe ich eigentlich auch eine Misskonfiguration der Server aus. Das hat bei mir immer gepasst. Insofern glaube ich nicht, dass dir mein Hinweis in vorigem Post was bringen wird.
Stellt sich die Frage, warum du ein Problem hast.
1.) Möglichkeit: Die Bilder die du hochlädst haben ein Format, das von WB nicht unterstützt wird. Was für eine Dateiendung haben die Bilder die du hochlädst?
2.) Möglichkeit: Beim Bilder einfügen bist du an der falschen Stelle in WB. Beschreib mal deine genaue vorgehensweise.
-
... Bilder die ich über die Media Verwaltung von WebsiteBaker in das media Verzeichnis hochlade haben bei mir auch die Dateirechte 644.
Das ist bei sab0-! ja eben nicht der Fall, da sind die Rechte "nur" 640, deshalb ist der Hinweis auf den tollen Support bei all-inkl.com richtig. Die werden helfen können.
-
Die Antwort von all-inkl.com lautet:
"Der Owner ist standardmäßig immer der FTP-Nutzer (w0*****). Andere Nutzer (wie etwa PHP User) werden gar nicht mehr unterstützt.
Der Standard chmod ist bei uns für Ordner ist 755 und der für Dateien 644."
Ich habe die Rechte alle Ordner und Dateien nachträglich nochmals angepasst. Doch auch dann werden neu hochgeladene Bilder auf 0640 gesetzt.
Das Problem besteht nicht, wenn Dateien per FTP hochgeladen werden.
Wie lässt sich das nun beheben?
-
Wie schon oben geschrieben steht bei mir an dieser Stelle:
Dateien: 0640 / rw-r-----
Verzeichnisse: 0750 / rwxr-x---
Hi, sorry für die doofe Frage, du kannst das nicht ändern auf 644 und 755?
Dafür sind die Schalter ja da.
Ich habe die Rechte des Verzeichnisses angepasst. Wenn ich danach ein Bild neu hochlade, setzt das System die Rechte dieses Bildes auf rw-r-----
Du hast den Ordner auf 755 gesetzt. Ein Bild ist aber eine Datei, deine Änderung hatte deshalb keine Auswirkung.
-
... Ich habe die Rechte alle Ordner und Dateien nachträglich nochmals angepasst. Doch auch dann werden neu hochgeladene Bilder auf 0640 gesetzt. ...
entschuldige, wenn ich nochmals nachbohre. Wie und wo genau lädst du die Bilder hoch? Über die Medienverwaltung von WB oder irgendwie über den CK Editor?
-
Mensch, Harald!!! Endlich die Lösung. Ich habe da schon mal auf "on" geklickt, aber da dann nichts weiter passiert ist, dachte ich, dass man hier nichts einstellen kann. Nachdem Du das jetzt aber so schreibst, habe ich es nochmal versucht. Man muss auf den Regler klicken. Aha. :?
Jetzt klappt das. Danke Dir!
-
Hallo,
super, freut mich, dass dein Problem gelöst werden konnte.
Was mich nur wundert, warum bei dir in den Servereinstellungen 640 drin stand. Standardmäßig (bei Neuinstall) müsste das eigentlich bei 644 (siehe scrennshots weiter oben) eingestellt sein.
Nachdem jetzt ja aber alles geht ist das schon mal ein guter Start ins neue Jahr :-D
-
Mensch, Harald!!! Endlich die Lösung. Ich habe da schon mal auf "on" geklickt, aber da dann nichts weiter passiert ist, dachte ich, dass man hier nichts einstellen kann. Nachdem Du das jetzt aber so schreibst, habe ich es nochmal versucht. Man muss auf den Regler klicken. Aha. :?
Jetzt klappt das. Danke Dir!
Die Ehre gebührt dbs ;)
-
Ja, danke dbs! (Y)
Ich wünsche Euch ein gutes neues Jahr und danke Euch für Eure stetigen Bemühungen jedes noch so verzwickte Problem zu lösen.