Beiträge von aws

    Hallo zusammen,

    ich klinke mich hier ebenfalls ein, da ich bei meinen Projekten exakt dasselbe Problem habe.

    Die Beschreibung von Tom trifft es perfekt: Nach dem Bestätigen der Sicherheitsabfrage beim Löschen einer Spalte, Reihe oder eines Containers friert die Oberfläche ein. Das Menü bleibt offen, reagiert auf Hover, aber nichts lässt sich mehr anklicken. Es hilft nur noch das Schließen des gesamten Programms über das Haupt-X.

    Da es bei mir auch bei verschiedenen Projekten auftritt, ist es kein Einzelfall.

    Viele Grüße
    AWS

    Da solltest nur eine kleine Änderung vornehmen
    aktuell
    const protocols = ["http://", "https://", "//"];
    const isExternal = protocols.some(function(proto) { return src.startsWith(proto); });

    if (isExternal) {
    const placeholder = document.createElement("div");


    Neu, nur kreuzfahrt.in-via.de (den oberen Code ersetzen mit dieser Zeile)
    // Blockiert NUR iFrames, die die In-Via Domain beinhalten
    if (src.includes("kreuzfahrt.in-via.de")) {
    const placeholder = document.createElement("div");


    Füge den Code einfach direkt auf der betroffenen Seite als Quelltext-Widget ein

    Gruss

    Armin

    Hallo nemessis,

    chapeau, das ist technisch völlig richtig gedacht!

    Hier kommt der entscheidende Punkt, warum der neue Code den Request trotzdem zuverlässig blockiert:

    Der Browser arbeitet HTML-Code stur von oben nach unten ab. Wenn er auf das iFrame-Tag stößt, baut er das Element zwar im Speicher auf, schickt aber nicht sofort im selben Bruchteil einer Millisekunde den Netzwerk-Request ins Internet. Da unser MutationObserver direkt am allerersten Element (<html>) ansetzt, ist er schneller als der Netzwerk-Prozess des Browsers.

    Ich habe es auf einer meiner Seiten mit mehreren externen iFrames live getestet. Es taucht kein einziger Aufruf zu den externen Servern mehr auf.

    Probiere es einfach mal mit einer Testseite aus.

    Grüße Armin (AWS)

    Hallo nemessis,

    ich habe den Code noch einmal optimiert. Der neue Code ist jetzt ein echter "Wächter", da die berechtigte Frage aufkam, wann das JavaScript eigentlich ausgeführt wird.

    Hier die kurze Erklärung: Damit das iFrame den Server nicht doch ganz kurz anfunkt, wartet dieses neue Skript nicht mehr, bis die Seite fertig geladen ist. Es läuft sofort an, während der Browser den Code von oben nach unten einliest. Dadurch fängt das Skript das iFrame exakt in dem Moment ab, in der es im Code auftaucht. Die originale Adresse wird sofort gelöscht und durch eine leere Seite ersetzt, bevor der Browser überhaupt den ersten Kontakt zum externen Server aufbauen kann.

    In meinem ersten Post einen kleinen Formatierungsfehler durch die Forensoftware, bei dem die logischen "ODER"-Zeichen (||) verschluckt wurden. Das ist hier nun auch korrigiert (danke Phil für den Hinweis)

    Ich habe das Ganze jetzt selbst nochmal bei mir auf einer Seite als Quelltext-Widget eingebunden und getestet: In der lokalen Zeta-Vorschau und im Offline-Browser werden alle iFrames absolut zuverlässig blockiert und der Platzhalter angezeigt. Sobald die Seite veröffentlicht und online ist, läuft alles ganz normal und die iFrames laden wie gewohnt.

    Hallo Stefan, hallo zusammen,

    alles klar, danke für den Hinweis, Stefan! Da habe ich den Fehler wohl zu schnell mit meinem eigenen „Klassiker“ nach Updates verwechselt und Christians Pfad nicht genau genug angeschaut.

    Weil bei mir das Zurücksetzen der Config-Datei nach Updates immer genau zu solchen Pfad-Problemen führt, dachte ich, das hilft hier vielleicht auch weiter. Aber da Christians Projekt ja im Standardverzeichnis liegt, war das wohl eine falsche Fährte von mir.

    Ich bin gespannt, was am Ende die echte Ursache ist!

    Gruß Armin

    Hallo Stefan,

    nein da war doch keine KI im Spiel. Ich muss das genau nach jedem Zeta Update machen da ich meine Projekte auf einem andern Ordner als der Zeta Standard Ordner habe. Ich habe mir daher die config Datei gesichert und kopiere sie nach jedem Update auf das Zeta Standard Verzeichnis.

    Es liegt mir fern für Verwirrung zu sorgen. Aber dieser Vorgang ist genau das was ich immer durchführen muss bei Zeta Updates

    Gruß

    Armin

    Seltsamerweise interpretiert das System hier die beiden senkrechten Striche (Doppelstriche), das logische "ODER" in JavaScript, als Emoji
    Entweder die Emojis gegen die Doppelstriche tauschen oder diesen Code verwenden. Der umgeht dies
    <style>
    /* Einfaches Basis-Styling für den Platzhalter */
    .zp-preview-iframe-placeholder {
    display: none;
    width: 100%;
    height: 350px;
    background-color: #f8f9fa;
    border: 2px dashed #007bff;
    border-radius: 6px;
    align-items: center;
    justify-content: center;
    text-align: center;
    padding: 20px;
    box-sizing: border-box;
    font-family: sans-serif;
    color: #333333;
    margin: 15px 0;
    }

    .zp-preview-iframe-placeholder p {
    margin: 0 0 5px 0;
    font-size: 16px;
    font-weight: bold;
    color: #007bff;
    }

    .zp-preview-iframe-placeholder span {
    font-size: 13px;
    color: #666666;
    }

    /* Steuerung über JavaScript-Klasse */
    body.is-zeta-preview .zp-preview-iframe-placeholder {
    display: flex;
    }

    body.is-zeta-preview iframe.preview-blocked {
    display: none !important;
    }
    </style>

    <script>
    (function() {
    function blockPreviewIframes() {
    const isLocalhost = window.location.hostname === "localhost" || window.location.hostname === "127.0.0.1";
    const isLocalFile = window.location.protocol === "file:";
         
    if (isLocalhost || isLocalFile) {
    document.body.classList.add("is-zeta-preview");
    const iframes = document.querySelectorAll("iframe");

    iframes.forEach(function(iframe) {
    const src = iframe.getAttribute("src");
             
    if (src && !iframe.classList.contains("preview-blocked")) {
    // Umgehung des Forum-Emoji-Bugs: Prüft http:// und https:// ohne die "||"-Striche
    const protocols = ["http://", "https://"];
    const isExternal = protocols.some(function(proto) { return src.startsWith(proto); });

    if (isExternal) {
    const placeholder = document.createElement("div");
    placeholder.className = "zp-preview-iframe-placeholder";
    placeholder.innerHTML = `
    <div>
    <p>🔄 iFrame-Vorschau blockiert</p>
    <span>Wird erst nach dem Veröffentlichen geladen.</span>
    </div>
    `;

    iframe.parentNode.insertBefore(placeholder, iframe);

    iframe.setAttribute("data-original-src", src);
    iframe.setAttribute("src", "about:blank");
    iframe.classList.add("preview-blocked");
    }
    }
    });
    }
    }

    if (document.readyState === "loading") {
    document.addEventListener("DOMContentLoaded", blockPreviewIframes);
    } else {
    blockPreviewIframes();
    }
    })();
    </script>

    Bin nicht 100% sicher ob es funktioniert
    Gehe auf die Seite, die das iFrame-Widget enthält.

    • Füge ein neues Widget vom Typ Quelltext hinzu.
    • Füge den kompletten Code dort ein


    <style>
    /* Einfaches Basis-Styling für den Platzhalter */
    .zp-preview-iframe-placeholder {
    display: none;
    width: 100%;
    height: 350px;
    background-color: #f8f9fa;
    border: 2px dashed #007bff;
    border-radius: 6px;
    align-items: center;
    justify-content: center;
    text-align: center;
    padding: 20px;
    box-sizing: border-box;
    font-family: sans-serif;
    color: #333333;
    margin: 15px 0;
    }

    .zp-preview-iframe-placeholder p {
    margin: 0 0 5px 0;
    font-size: 16px;
    font-weight: bold;
    color: #007bff;
    }

    .zp-preview-iframe-placeholder span {
    font-size: 13px;
    color: #666666;
    }

    /* Steuerung über JavaScript-Klasse */
    body.is-zeta-preview .zp-preview-iframe-placeholder {
    display: flex;
    }

    body.is-zeta-preview iframe.preview-blocked {
    display: none !important;
    }
    </style>

    <script>
    (function() {
    function blockPreviewIframes() {
    const isLocalhost = window.location.hostname === "localhost" || window.location.hostname === "127.0.0.1";
    const isLocalFile = window.location.protocol === "file:";
         
    if (isLocalhost || isLocalFile) {
    document.body.classList.add("is-zeta-preview");
    const iframes = document.querySelectorAll("iframe");

    iframes.forEach(function(iframe) {
    const src = iframe.getAttribute("src");
             
    if (src && (src.startsWith("http://") || src.startsWith("https://")) && !iframe.classList.contains("preview-blocked")) {
    const placeholder = document.createElement("div");
    placeholder.className = "zp-preview-iframe-placeholder";
    placeholder.innerHTML = `
    <div>
    <p>🔄 iFrame-Vorschau blockiert</p>
    <span>Wird erst nach dem Veröffentlichen geladen.</span>
    </div>
    `;

    iframe.parentNode.insertBefore(placeholder, iframe);

    iframe.setAttribute("data-original-src", src);
    iframe.setAttribute("src", "about:blank");
    iframe.classList.add("preview-blocked");
    }
    });
    }
    }

    if (document.readyState === "loading") {
    document.addEventListener("DOMContentLoaded", blockPreviewIframes);
    } else {
    blockPreviewIframes();
    }
    })();
    </script>


    Der Code blockiert in der lokalen Zeta-Vorschau das automatische Laden externer iFrames und zeigt stattdessen einen statischen Platzhalter an. Dadurch werden massenhafte Server-Aufrufe während der Bearbeitung verhindert, während auf der veröffentlichten Website alles wie gewohnt lädt.

    Ungetestet, versuche es einfach mal

    Grüße
    Armin /AWS)

    Hallo zusammen,

    das Problem liegt sehr wahrscheinlich an einer Überschreibung der Konfigurationsdatei Zeta Producer.dll.config durch das Update.

    Wenn ihr – wie viele von uns – einen benutzerdefinierten Pfad für eure Projektdaten verwendet (z. B. auf einem anderen Laufwerk oder in einem Cloud-Synchronisations-Ordner wie OneDrive), habt ihr diesen in der Config-Datei über folgenden Key definiert:

    XML


    Code
    <add key="alternativeCurrentUserStorageBaseFolderPath" value="D:\Dokumente\Zeta Producer 17" />

    Was passiert bei dem Update?

    Das Update setzt die Zeta Producer.dll.config wieder auf die Standardwerte zurück. Zeta Producer sucht danach wieder im Windows-Standardpfad unter C:\Users\[Benutzername]\Documents\....

    Die Fehlermeldung von Christian zeigt genau das:

    Zitat

    Fatal error: Failed opening required 'C:/Users/cfuch/OneDrive/...'

    Hier versucht PHP (für die lokale Vorschau), Dateien aus dem Standardpfad zu laden, obwohl die echten Projektdaten vermutlich ganz woanders liegen oder die Verknüpfung durch den Reset der Config-Datei zerschossen wurde.

    Die Lösung:

    1. Schließt Zeta Producer komplett.
    2. Öffnet die Datei Zeta Producer.dll.config im Zeta Producer-Installationsverzeichnis mit einem Texteditor (z. B. Notepad).
    3. Sucht nach der Sektion <appSettings> und fügt euren individuellen Pfad-Key wieder ein:

      XML


      Code
      <add key="alternativeCurrentUserStorageBaseFolderPath" value="DEIN_VTRTRAUTER_PFAD_HIER" />
    4. Datei speichern und Zeta Producer neu starten.
    5. Einmal das Projekt komplett neu generieren lassen (Strg + F5), damit auch die Vorschau-Pfade für PHP neu geschrieben werden.

    Danach sollte die Vorschau und das Projekt wieder fehlerfrei laufen!

    Viele Grüße
    Armin

    Aktiv vs. Passiv (FTPS-Problem bei DomainFactory)

    Laut Log knallt es genau in der Funktion ActivePassiveDetectorGuard.doGuard(). Anscheinend versucht Zeta Producer herauszufinden, ob der Server passives oder aktives FTP bevorzugt. DomainFactory reagiert bei FTPS extrem empfindlich, wenn der Modus mitten im Upload wechselt oder die Ports gesperrt sind.

    Versuch mal auch folgendes: in den erweiterten FTP-Einstellungen (wo du vorhin die Haken weggemacht hast) den Übertragungsmodus fest auf „Passiv (PASV)“ einstellen, anstatt ihn auf „Automatisch“ zu belassen.

    Leider zu früh gefreut. Der Verbindungstest ist mit TLS 1.2 / 1.3 bzw. nur mit TLS 1.3 erfolgreich. Der Upload beginnt und dann erscheint irgendwann ein Socket-Fehler, und dann ist Schluss, sowohl mit TLS 1.2 / 1.3 als auch nur mit TLS 1.3.

    OK, dann muss das mal der Zeta Support checken. Bei meinem Hoster Netcup.de läuft der Transfer problemlos !

    Hallo Support-Team,

    nach dem Update auf Version 17.2.1 schlug der Verbindungstest bei „FTP mit SSL“ (Hoster: Netcup) sofort mit der Meldung "SSL 3.0 has been deprecated..." fehl.

    Ursache & Lösung: In den erweiterten Einstellungen waren standardmäßig noch die Haken bei SSL 3.0, TLS 1.0 und TLS 1.1 gesetzt. Erst nachdem ich diese manuell entfernt und nur noch TLS 1.2 / 1.3 aktiv gelassen habe, lief der Test wieder durch.

    Es scheint, dass das neue Update die Verbindung komplett blockiert, sobald SSL 3.0 in den Optionen aktiv ist, statt einfach auf TLS auszuweichen. Eventuell solltet ihr die Standard-Haken bei Neuinstallationen/Updates für die alten Protokolle direkt entfernen.

    Viele Grüße
    Armin (AWS)

    Hallo Stefan,

    das ist wirklich sehr seltsam. Die Option „Footer anzeigen“ ist bei mir im Design-Modus natürlich aktiviert – sonst hätte der Footer ja nach dem Layout-Wechsel auf Locus oder durch meinen CSS-Fix auch nicht plötzlich auftauchen können.

    Ich bin beim Testen exakt wie folgt vorgegangen:

    1. Ich habe in Zeta Producer ein komplett neues Projekt angelegt.
    2. Als Vorlage habe ich gezielt das Beispiel layouts/campfire-responsive-modelagentur/ ausgewählt.
    3. Danach habe ich angefangen, den Header, den Content und schließlich meinen individuellen Footer über ein HTML-Quelltext-Widget einzubauen.

    Und genau in dieser Konstellation blieb der Footer im Browser komplett unsichtbar. Erst als ich die Zwangsbefehle in mein CSS eingebaut habe, war er da.

    Liegt es vielleicht speziell an dieser Beispielvorlage der Modelagentur oder an einer CSS-Kollision mit den dortigen Demodaten? Ich weiß es ehrlich gesagt nicht, aber vielleicht hilft euch dieser genaue Ablauf ja beim Nachstellen.

    Viele Grüße, Armin

    Hallo Steffen,

    ich konnte das Problem mittlerweile eingrenzen und lösen. Es lag wohl tatsächlich an einer CSS- bzw. Rendering-Kollision, die exakt so nur innerhalb des Campfire-Layouts im Browser auftritt. Das Template blendet den Footer aus, komprimiert ihn auf 0px Höhe oder lässt ihn durch andere Container überlagern.

    Wichtiger Hinweis dazu: Ich nutze Footer dieser Art in fast all meinen Projekten und hatte bei anderen responsive Layouts in Zeta Producer noch nie Probleme damit. Dass der Code fehlerfrei ist, hat ja auch der Test mit dem Locus-Layout gezeigt.

    Ich musste den Footer nun im CSS mit folgenden expliziten Anweisungen zur Sichtbarkeit zwingen, damit er im Campfire-Layout ordnungsgemäß im Browser gerendert wird:

    display: block !important; visibility: visible !important; opacity: 1 !important; min-height: 200px !important; position: relative !important; z-index: 99999 !important; clear: both !important;

    Vielleicht hilft euch dieser Hinweis, um die Container-Struktur oder die Standard-CSS-Eigenschaften des Campfire-Templates bei einem zukünftigen Update mal zu überprüfen.

    Ich arbeite mit Zeta Producer V17.2

    Freundliche Grüße, Armin

    Hallo Steffen,

    danke für deine Antwort. Habe verschiedene Szenarien getestet. Ja, der Pfad bleibt immer der gleiche, solange der Artikel vorhanden ist. Und der Kunde bevorzugt jetzt doch lieber den Austausch des Files (Bildes) über das Online CMS Widget. 😀

    Wer sich mal anschauen möchte, wie elegant das Zeta-eigene Online CMS Widget direkt in der Praxis aussieht und wie simpel der Kunde darüber seine Karte austauschen kann, kann sich das hier mal live ansehen:

    👉 http://www.waldgaststaette-schuetzenhaus.de/sonntagsempfehlung.php

    Ist wirklich eine super Sache und nach einigen Diskussionen mit dem Kunden komfortabel gelöst!

    Grüße

    Armin


    Hallo Zeta-Producer-Support-Team,

    bei meinem aktuellen Projekt habe ich einen individuellen HTML/CSS-Footer hinterlegt, bei dem es im Layout Campfire Responsive zu einem Rendering-Problem kommt.

    Problembeschreibung:

    • Wenn das Layout Campfire Responsive aktiv ist, bleibt der Footer-Bereich im Bearbeiten-Modus, im Design-Modus und in der Live-Vorschau komplett leer. Der Inhalt wird in diesem Layout ausschließlich im Wireframe-Modus sowie in der Tabellenansicht (F8) angezeigt.
    • Wichtige Erkenntnis: Wechsle ich das Layout testweise auf Locus Responsive, wird der Footer in allen Ansichten (inkl. Live-Vorschau) absolut fehlerfrei und top angezeigt. Der Code an sich funktioniert also.

    Der Footer-Inhalt umfasst ca. 5.000 Zeichen und besteht aus einem <style>-Block, einem <footer>-Tag, einem Grid-Layout, Icon-Links sowie internen oid://page/-Verlinkungen.

    Fragen an den Support:

    • Gibt es im Layout Campfire Responsive eine spezifische CSS-Kollision, eine Begrenzung oder eine Container-Struktur im Footer-Bereich, die das Rendern dieses Codes blockiert?
    • Wie kann ich der Ursache innerhalb des Campfire-Layouts am besten auf den Grund gehen, um den Footer auch dort zum Laufen zu bringen?

    Vielen Dank für Ihre Unterstützung!

    AWS (Armin)

    Hallo Zeta-Team,

    ich habe eine technische Frage zum Dateisystem des Online CMS und hoffe, ihr könnt mir hier mit eurem Fachwissen weiterhelfen.

    Kurz zum Hintergrund: Ich habe ein Projekt für eine Gaststätte umgesetzt. Um dem Betreiber (der technisch ein absoluter Laie ist) die Pflege so leicht wie möglich zu machen, habe ich für den Austausch der regulären Speisekarte bereits ein eigenes, kleines PHP/HTML-Upload-Skript geschrieben. Über ein simples Fenster wählt der Kunde die Datei aus, gibt ein Passwort ein und die alte Karte wird (bei identischem Dateinamen) einfach überschrieben. Das funktioniert absolut reibungslos und macht den Kunden komplett unabhängig!

    Das aktuelle Anliegen (Die Sonntagsempfehlung): Zusätzlich gibt es jede Woche eine wechselnde "Sonntagsempfehlung", die als JPG-Bild hochgeladen wird. Um auch hier unabhängig zu sein, habe ich das in einem Zeta Online CMS integriert. Derzeit geht der Kunde den Weg über das CMS, ruft den Artikel (editieren) auf und tauscht dort die Bild aus.

    Beim Blick auf den Server ist mir nun aufgefallen, dass das hochgeladene Bild für diesen spezifischen Artikel in folgendem Pfad abgelegt wird (Beispielpfad einer meiner Subdomains:) /roland.awinkler-website.de/httpdocs/assets/php/CMS_DATA/2130/assets/

    Meine konkrete Frage: Ist dieser Verzeichnispfad (insbesondere die ID wie z.B. 2130) für diesen Artikel immer identisch und fix, solange der Artikel selbst nicht gelöscht wird?

    Der Gedanke dahinter: Wenn dieser Pfad konstant bleibt, könnte ich meinem Kunden diesen Upload-Slot ganz elegant ebenfalls in mein eigenes, kleines Upload-Tool packen. Dann müsste er den Weg über das Online CMS gar nicht mehr gehen und könnte sowohl die Speisekarte als auch die Empfehlung über dieselbe simple Maske aktualisieren.

    Könnt ihr mir bestätigen, dass man sich auf diesen Pfad dauerhaft verlassen kann, oder gibt es Szenarien (z.B. beim erneuten Publizieren), bei denen sich diese Ordner-ID ändert?

    Vielen Dank im Voraus für eure Unterstützung!

    Beste Grüße
    AWS (Armin)

    Viele Grüße,

    Hallo Support-Team,

    seit dem Update auf die Version 17.2 kann ich in einem meiner Projekte den Layout-Designer nicht mehr öffnen. Es erscheint sofort eine Fehlermeldung, die den Start blockiert. Ein Wechsel des Layouts ist dadurch ebenfalls nicht möglich.

    Die genaue Fehlermeldung lautet:

    Zitat

    Der Layout-Designer konnte nicht geöffnet werden. Datei 'C:\Users\armin\AppData\Local\Temp\ZP-LayoutEditor-...\Campfire Responsive\variants\anderer\values.json' ist nicht vorhanden.

    Zu meiner Umgebung / Was ich bereits versucht habe:

    • Projekt-Pfad: Meine Projektdaten liegen auf einem separaten Laufwerk unter D:\Dokumente\Zeta Producer 17\Projects\GV Busenbach\. Dies funktionierte vor dem Update einwandfrei.
    • Cache gelöscht: Ich habe bereits die temporären Ordner (ZP-LayoutEditor-...) unter %localappdata%\Temp manuell gelöscht – ohne Erfolg. Beim Neustart läuft der Fehler wieder auf.
    • Layout-Wechsel: Ein Wechsel des Layouts ist blockiert, da der Editor gar nicht erst lädt.

    Wie kann ich das Projekt reparieren oder die Struktur manuell zurücksetzen, damit der Designer die Datei wieder findet?

    Vielen Dank für Ihre Hilfe

    Gruß

    AWS (Armin)

    Hallo Support-Team,

    vielen Dank, dass die WAVE-Fehlermeldungen beim Zeta Cookie Consent mit dem neuen Update behoben wurden!

    Leider taucht seit dem Update auf Version 17.2 nun ein neuer Fehler im Hauptmenü auf, wenn ich die Option "Kein Logo anzeigen" wähle. Das Logo-Bild wird zwar entfernt, aber der umschließende Link zur Startseite bleibt komplett leer im Code stehen.

    WAVE meldet hier einen kritischen "Empty link"-Fehler, da jeglicher Textinhalt fehlt:

    HTML


    Code
    <li class="logo hidden" style="max-width: 1463.4px;">
        <a href="index.html"></a>
    </li>

    Sobald ich das Logo testweise wieder aktiviere, ist der Fehler weg (da das Bild samt Alternativtext wieder da ist). Wenn das Logo abgeschaltet ist, müsste im Template entweder das gesamte <li> entfernt oder der Link mit einem aria-label="Startseite" versehen werden.

    Bitte korrigieren Sie diesen Bug im nächsten Update.

    Viele Grüße
    Armin

    Hallo Bernd,

    ich habe das gerade mal getestet und du hast recht, da wird tatsächlich eine .html statt der PDF geladen.

    Das Problem liegt aber sehr wahrscheinlich nicht an Zeta Producer selbst, sondern an dem verwendeten Widget. Das ist ein externes Widget von zp-widget.de und vermutlich schlichtweg nicht kompatibel mit der neuen Zeta Version 17.x.

    Da müsstest du direkt beim Entwickler des Widgets nachfragen, ob es da ein Update gibt. Hier ist der Link dazu: 👉 https://www.widget-zp.de/

    Als schnellen Workaround kannst du die PDF ja erst mal über einen ganz normalen Standard-Button von Zeta Producer einbinden, das funktioniert auf jeden Fall.

    Viele Grüße
    Armin

    Hallo Stefan,

    ich wende mich noch einmal mit einer technischen Beobachtung an Sie, da ich anderes Problem nun weiter eingrenzen konnte.

    Um die Anforderung einer automatischen Bestätigungs-E-Mail (Autoreply) zu erfüllen, habe ich ein eigenes Formular inklusive PHP-Anbindung entwickelt. Zuerst hatte ich den entsprechenden Code (HTML, CSS und Script) in einem Text-Widget (Quelltext Ansicht) platziert. Dabei trat jedoch ein Fehler auf: Der notwendige Formular-Tag (<form id="sc-anmeldung-f" class="sc-form" novalidate>) wurde nach jedem Schließen und Neustarten von Zeta Producer aus dem Quelltext entfernt.

    Ich habe das Ganze nun in ein Quelltext-Widget verschoben, dort bleibt der Code stabil erhalten. Allerdings ist das Arbeiten dort recht unkomfortabel, da die Vorschau des Styles im Editor komplett entfällt und man so "blind" arbeiten muss.

    Daher meine Frage an Sie:

    1. Ist dieses Verhalten (dass das Text-Widget bestimmte Form-Tags beim Speichern/Neustarten bereinigt) ein bekanntes Phänomen?
    2. Gibt es eine Empfehlung, wie man komplexere, externe Formular-Strukturen so in Zeta Producer einbindet, dass der Code erhalten bleibt, aber eine visuelle Bearbeitung bzw. Vorschau dennoch möglich ist?

    Vielen Dank für Ihre Einschätzung und einen Hinweis, wie man hier am besten verfährt.

    Beste Grüße

    Armin

    Hallo zusammen,

    leider reicht mir die bloße Anzeige der Formular-Werte auf dem Bildschirm nicht aus. Da das Projekt hohe Anforderungen an die Nachvollziehbarkeit und Rückfragenfreiheit stellt, ist eine automatische Bestätigungs-E-Mail (Autoreply) an den Absender zwingend erforderlich. Der User muss direkt nach dem Absenden eine schriftliche Bestätigung über den Eingang seiner Nachricht erhalten.

    Da das Standard-Widget dies – wie von Stefan S. bestätigt – systemseitig nicht unterstützt, werde ich nun die Lösung über ein eigenes PHP-Skript weiterverfolgen, um diese Funktionalität stabil abzubilden.

    Vielen Dank noch einmal für eure Einschätzungen!

    Beste Grüße Armin

    Hallo zusammen,

    ich nutze für ein aktuelles Webprojekt das Standard-Formular-Widget.

    Derzeit ist die Konfiguration so eingestellt, dass die E-Mails aus dem Formular an eine feste E-Mail-Adresse des Seitenbetreibers gesendet werden. Nun wurde der Wunsch geäußert, dass dieser Prozess erweitert wird:

    Wenn ein User das Formular ausfüllt (Name, E-Mail-Adresse, Nachricht etc.), soll nicht nur der Betreiber eine Benachrichtigung erhalten, sondern automatisch auch eine Bestätigungs-E-Mail an die E-Mail-Adresse des Users gesendet werden, die dieser im Formular angegeben hat.

    Aktuell versuche ich dies über eine externe HTML/PHP-Lösung außerhalb des Widgets zu lösen, um die E-Mail-Funktionalität flexibler zu gestalten.

    Meine Frage:
    Gibt es eine Möglichkeit, dies direkt innerhalb des Zeta Producer Formular-Widgets zu konfigurieren, oder ist der Weg über ein eigenes PHP-Skript der Standard-Workaround?

    Vielen Dank im Voraus für eure Hilfe und Expertise!

    Beste Grüße
    Armin

    Was wollen Sie hier dem Forum Mitgliedern mitteilen?

    Beste Grüße

    Bin der gleichen Meinung wie MichaelM. Was soll hier mitgeteilt werden ? Ich nutze dieses tolle Forum um bei Problemen Unterstützung, noch besser um eine Lösung zu finden. Wer wie wo was mit KI macht ist ok. Das ist aber doch kein Zeta Problem das hier diskutiert wird. Ich arbeite selbst auch mit diversen KI'S. Aber das sollte man doch nicht hier diskutieren
    Beste Grüße
    Armin

    Hallo Steffen,

    vielen Dank für Ihre Rückmeldung.

    Ja, der Code steckt tatsächlich in einem Text-Widget über die Quelltext-Ansicht. Genau so habe ich das auch schon unter Zeta Producer 16.8 gemacht, dort lief derselbe Code immer ohne Probleme.

    Den Test im Quelltext-Widget mache ich bei nächster Gelegenheit (never change a running System). Interessieren würde mich aber auch, ob sich zwischen 16.8 und 17.x bei der Verarbeitung von Bildern bzw. OIDs etwas geändert hat. Die OIDs selbst scheinen ja zu funktionieren, da dieselben Bilder als CSS-Hintergrundbild problemlos angezeigt werden.

    Außerdem glaube ich, dass Ihre Antwort eventuell abgeschnitten wurde, da der letzte Satz mitten im Text endet. Falls da noch etwas folgen sollte, freue ich mich über eine kurze Ergänzung.

    Viele Grüße

    Armin (aws)

    Hallo Zeta Team,

    ich brauche eure Hilfe. Seit meinem Update von Version 16.8 auf Zeta Producer 17 Business habe ich ein richtig seltsames Problem mit integrierten Bildern in meinen eigenen HTML-Widgets.

    Was passiert?
    Wenn ich ein Bild ganz normal über das HTML-Tag einbinde, wird es total unzuverlässig angezeigt. In der Offline-Vorschau und auch später live ist das Bild mal da, nach dem nächsten Laden oder Upload plötzlich wieder komplett weg oder zerschossen. Unter Zeta 16.8 lief exakt derselbe Code immer bombenfest!

    Hier ein Beispiel, wie der HTML-Code aufgebaut ist, der unter 16.8 nie Probleme gemacht hat:

    <div class="highlight-container">
    <!-- Unter 16.8 top, seit v17 fliegt mir das Bild um die Ohren: -->
    <img src="oid://image/bildxxx" alt="Testbild" class="highlight-graphic">
    </div>

    Mein aktueller (anstrengender) Workaround:
    Ich habe herausgefunden: Wenn ich das Bild aus dem HTML-Code rauswerfe und es stattdessen als CSS-Hintergrundbild (background-image: url('oid://image/...');) einbaue, klappt es perfekt und bleibt stabil.

    HTML
    <div class="highlight-container">
    <!-- So bleibt es stabil, verlangt aber für jedes Bild extra CSS: -->
    <div class="highlight-graphic-box" data-stroid="oid://image/bildxxx"></div>
    </div>

    CSS
    .highlight-graphic-box {
    width: 220px;
    height: 200px;
    background-image: url('oid://image/bildxxx');
    background-size: cover;
    background-position: center;
    display: block;
    }

    Die OIDs stimmen also, aber Zeta 17 scheint die klassischen <img>-Tags innerhalb von eigenen HTML-Objekten irgendwie sporadisch zu verschlucken oder im Cache zu verlieren. Da ich das ungerne bei jedem Bild per CSS umbauen möchte, dachte ich, ich frage mal bei euch nach. 😉

    Ist dazu schon was bekannt oder hat das Phänomen noch jemand seit der v17.xx beobachtet?

    Freue mich auf euer Feedback und viele Grüße!

    Armin (aws)

    Hallo URO,

    Die Lösung ist ganz einfach. Im Panorama-Layout, oder auch anderen Layouts, sind die Header-Grafiken standardmäßig über viele Seiten hinweg miteinander verknüpft. Du musst diese Verknüpfung lediglich trennen.

    Gehe dazu einfach wie folgt vor:

    1. Verknüpfungen aufheben

    1. Gehe auf deine Startseite und fahre mit der Maus über die Header-Grafik, um den Bearbeitungsmodus zu aktivieren.
    2. Klicke auf das Menü-Symbol (die drei Striche/Burger-Menü) direkt an der Grafik.
    3. Wähle im Menü den Punkt „Verknüpfungen“ aus. Hier siehst du nun eine Liste aller Seiten, auf denen diese Grafik aktuell gespiegelt wird.
    4. Entferne hier einfach alle Verknüpfungen und bestätige das Ganze mit dem Button „Anwenden“. Jetzt ist jede Seite für sich eigenständig.

    2. Neue Bilder auf den Unterseiten einfügen

    Nachdem die Verknüpfung gelöst ist, kannst du den Unterseiten ganz einfach eigene Bilder zuweisen:

    1. Wechsle zu der gewünschten Haupt- oder Unterseite, die ein neues Bild bekommen soll.
    2. Tipp für mehr Übersicht: Schalte oben rechts auf die Wireframe-Ansicht um.
    3. Klicke in der Sektion „Header“ auf das „+“-Symbol.
    4. Wähle dein neues Wunschbild aus – fertig!

    Das machst du dann einfach für alle Seiten, die ein individuelles Motiv erhalten sollen.

    Grüße
    AWS Armin

    Hallo Zeta-Producer-Team,

    soeben bin ich bei der Prüfung meiner Website mit dem WAVE-Tool auf ein Problem mit dem Cookie-Consent-Widget in der Version 17.1.1 gestoßen, das dringend Aufmerksamkeit erfordert.

    Es treten 14 Fehler vom Typ "Empty form label" auf. Alle betroffenen Checkboxen im Consent-Widget haben keinen zugänglichen Textinhalt, was sie für Screenreader-Nutzer unbrauchbar macht. Da dieses Verhalten in der Version 16.8 noch nicht vorhanden war, handelt es sich hier offensichtlich um eine Regression, die sich mit dem Update eingeschlichen hat.

    Da Zeta Producer für viele professionelle Webseiten genutzt wird, ist dies ein sehr kritisches Thema für die Barrierefreiheit unserer Projekte. Ich bitte daher höflich, dies nicht als "Feature-Wunsch für später" zu betrachten, sondern zeitnah als Bug zu korrigieren. Eine barrierefreie Umsetzung sollte bei einem solch zentralen Element Standard sein.

    Über eine kurze Rückmeldung, ob hier kurzfristig eine Lösung geplant ist, würde ich mich sehr freuen.

    Beste Grüße
    Armin (AWS)

    Hallo wpelz,

    das klingt komplizierter, als es ist. Die Fehlermeldung bedeutet lediglich, dass Zeta Producer nach dem Update den Pfad zu einem Bild im Kopfbereich (Header) verloren hat. Da das System die Datei nicht mehr findet, blockiert es vorsichtshalber den Upload.

    Probieren Sie am besten zuerst den schnellsten Weg (Weg 1). Sollte das nicht klappen, nehmen wir den sicheren Umweg (Weg 2):

    Weg 1: Das Bild direkt austauschen (Schnellste Variante)

    1. Öffnen Sie die Seite "Kernkompetenzen" ganz normal im Bearbeiten-Modus.
    2. Fahren Sie mit der Maus über den Header-Bereich (ganz oben auf der Seite) und wählen Sie dort Bearbeiten aus.
    3. Der aktuelle Header öffnet sich. Tauschen Sie hier einfach das Bild direkt aus (neu laden/auswählen) und speichern Sie ab.

    Sollte das Problem danach weiterhin bestehen, nutzen wir Weg 2:

    Weg 2: Den Header neu anlegen

    1. In die Spaltenansicht wechseln: Öffnen Sie die Seite "Kernkompetenzen" im Zeta Producer und drücken Sie auf Ihrer Tastatur die Taste [F8]. Dadurch wechselt die Ansicht in den sogenannten Spaltenmodus. Ihre Seite wird nun übersichtlich in die einzelnen Bereiche unterteilt (z. B. Banner, Header, Standard, Footer).
    2. Alten Header löschen: Suchen Sie den Bereich Header (bzw. den fehlerhaften Header-Artikel dort) und löschen Sie diesen.
    3. Ansicht wechseln & neuen Header anlegen: Schließen Sie danach den Spaltenmodus wieder. Wählen Sie dafür im Zeta Producer oben rechts den Punkt "Wireframe" aus. In dieser Ansicht können Sie nun ganz einfach einen neuen Header-Artikel anlegen und Ihr gewünschtes Bild neu einfügen.

    Sobald der neue Header sitzt, ist die Verknüpfung zum Bild wieder sauber hinterlegt und der Upload Ihrer Website sollte wieder wie gewohnt und fehlerfrei durchlaufen.

    AWS

    Kann ich da einsteigen mit dem Widget Cookies ?
    Fehler im Cookie-Widget: Farbauswahl bei „Alle akzeptieren“-Button nicht möglich

    Fehlerbeschreibung: Ich versuche derzeit, das Design des Cookie-Widgets anzupassen. Dabei tritt ein spezifisches Problem bei der Konfiguration des Buttons „Alle akzeptieren“ auf.

    Details zum Fehler:

    • Problem: Sobald ich versuche, die Hintergrundfarbe oder die Textfarbe für den „Alle akzeptieren“-Button auszuwählen, springt der Fokus der Benutzeroberfläche automatisch in die nächste Sektion („Button Alle ablehnen“).
    • Auswirkung: Es ist mir dadurch unmöglich, die farbliche Gestaltung des Akzeptieren-Buttons zu ändern, da die Auswahlfelder nicht aktiv bleiben bzw. sofort übersprungen werden.

      Zeta Producer 17.1.0 Business

      Grüße
      Armin Winkler