Beiträge von Uwe Keim

    Noch nicht in der aktuell veröffentlichten Version 17.2.5. Die Korrektur für die fehlenden Größenangaben bei Bildern im Texteditor wird zunächst für die kommende Hauptversion umgesetzt.

    Hallo Heidi,

    damit wir die Ursache eingrenzen können, bräuchten wir bitte noch folgende Angaben:

    1. Welche Zeta-Producer-Version verwenden Sie, und wann wurde die Website zuletzt vollständig veröffentlicht?
    2. Ist im Formular der Versand per SMTP aktiviert? Bei welchem Anbieter liegen die Website und das empfangende Postfach?
    3. Wird die Formularmail direkt in diesem Postfach empfangen oder über eine Weiterleitung beziehungsweise einen david-Mailserver verarbeitet?

    Besonders hilfreich wären die vollständigen Mail-Kopfzeilen (Header/„Original anzeigen“) von einer im Spam gelandeten und einer korrekt zugestellten Formularmail. Relevant sind insbesondere From, Reply-To, Return-Path, Authentication-Results und die Received-Zeilen. Bitte die Originale wegen der enthaltenen Adressen und technischen Angaben per privater Konversation an mich schicken, nicht öffentlich hier einstellen. Kennwörter benötigen wir nicht.

    Der aktuelle Formularcode verwendet die im Formular eingegebene Besucheradresse als Antwortadresse (Reply-To). Als eigentliche Absenderadresse wird die erste konfigurierte Empfängeradresse eingesetzt. Der im Mailprogramm angezeigte Name allein zeigt deshalb noch nicht, welche Adresse technisch als Absender verwendet wurde. Mit den Headern können wir das und die Ergebnisse der Absenderprüfungen vergleichen.

    Freundliche Grüße
    Uwe

    ich habe die Angaben und die öffentlich erreichbare Shop-Installation geprüft. Die von Ihnen verwendeten SMTP-Daten smtps.udag.de, Port 587 und TLS entsprechen weiterhin den offiziellen Vorgaben von united-domains. Der SMTP-Server ist außerdem erreichbar und akzeptiert sowohl TLS 1.2 als auch TLS 1.3. Auf den gezeigten Bildschirmfotos ist daher kein offensichtlicher Eingabefehler erkennbar.

    Der entscheidende Unterschied zwischen Formular und Shop:

    Beide Komponenten verwenden zwar PHPMailer, aber nicht dieselbe ausgelieferte Version und auch nicht dieselbe TLS-Konfiguration. Der Formularmailer prüft das Serverzertifikat nicht. Der Shop prüft es dagegen, solange dort „SSL-Fehler ignorieren“ auf „Nein“ steht. Deshalb kann das Formular mit denselben SMTP-Daten funktionieren, während der Shop beim TLS-Verbindungsaufbau scheitert. „Called STARTTLS without being connected“ ist sehr wahrscheinlich nur der Folgefehler der zuvor abgebrochenen TLS-Verbindung.

    Bitte testen Sie zunächst nur Folgendes:

    1. Server smtps.udag.de, Port 587 und TLS unverändert lassen.

    2. In den Shop-Einstellungen ausschließlich „SSL-Fehler ignorieren“ auf „Ja“ setzen.

    3. Die Website vollständig veröffentlichen.

    4. Danach eine Testbestellung durchführen.

    Wenn der Versand damit funktioniert, ist eine Zertifikats- beziehungsweise CA-Kettenprüfung auf dem Webserver die Ursache. Die Option wäre dann zunächst ein Workaround; dauerhaft sollte united-domains den Zertifikatsspeicher der eingesetzten PHP-/OpenSSL-Umgebung prüfen beziehungsweise aktualisieren.

    Falls es weiterhin nicht funktioniert, aktivieren Sie bitte zusätzlich das SMTP-Debugging, veröffentlichen erneut vollständig und führen genau eine weitere Testbestellung aus. Die dabei entstehende vollständige Meldung beziehungsweise das Shop-Protokoll würde den nächsten Fehlerpunkt zeigen.

    Zusätzlich fällt auf, dass Ihre Website zwar mit Zeta Producer 16.7 erzeugt wurde, die öffentlich installierte Shop-Komponente aber noch Version 15.1.0.0 meldet (Die Kollegen Stefan/Steffen mögen mich bitte korrigieren, falls ich hier falsch liege). Diese ist deutlich älter und enthält unter anderem eine alte PHPMailer-Version sowie eine inzwischen überholte Behandlung des gespeicherten SMTP-Kennworts. Nach dem oben genannten Test wäre deshalb auch eine vollständige Aktualisierung der Shop-Komponente sinnvoll.

    Die Ursache lag nicht am Token-Guthaben. Zusätzlich zum Tokenkonto galt serverseitig ein kurzfristiges Limit von 20 KI-Anfragen pro Lizenz und Minute. In den Protokollen ist zu sehen, dass die 21. Anfrage innerhalb einer Minute deshalb mit der kurzen Wartezeit-Meldung abgewiesen wurde. Der dabei angebotene Wechsel auf Business war in diesem Zusammenhang irreführend und nicht erforderlich.

    Wir haben das Limit für solche sequenziellen Stapelläufe auf 60 Anfragen pro Minute erhöht. Das globale Schutzlimit und die Begrenzung gleichzeitig laufender Anfragen bleiben bestehen. Die Änderung erfolgt ausschließlich serverseitig; Sie benötigen dafür kein Programmupdate.

    Bitte probieren Sie die Alt-Text-Erzeugung erneut.

    der neue Test von PlanungWR hilft bei der Eingrenzung: Nach dem Umbenennen des gesamten Ordners „Dokumente\Zeta Producer 17“ werden nur noch die allgemeinen Settings-Dateien angelegt; der WebView2-Benutzerdatenordner entsteht gar nicht. Der Fehler tritt damit sehr früh beim Erzeugen der WebView2-Umgebung auf. Dass dabei keine aktuelle Protokolldatei geschrieben wird, ist in diesem Fall eine Folge des frühen Abbruchs und kein zusätzlicher Fehler.

    Ein beschädigtes Zeta-Producer-Profil oder alte Projekteinstellungen können wir dadurch inzwischen praktisch ausschließen.

    Vor der weiteren Windows-Diagnose sollten wir bei PlanungWR noch sicherstellen, dass wirklich keine Dateien der mitgelieferten WebView2-Runtime aus der vorherigen Installation übrig geblieben sind. Eine normale Neuinstallation ersetzt vorhandene Restdateien nicht in jedem Fall vollständig. Bei dirk.hustadt ist dieser Schritt nach seiner Beschreibung bereits erfolgt, weil er den kompletten Applications-Ordner gelöscht und anschließend neu installiert hat.

    PlanungWR, bitte daher noch einmal folgendermaßen vorgehen:

    1. Zeta Producer vollständig beenden.
    2. Zeta Producer deinstallieren.
    3. Falls anschließend noch vorhanden, diesen Ordner manuell löschen oder umbenennen:
    %LOCALAPPDATA%\Zeta Producer 17\Applications\WebView2
    4. Windows neu starten.
    5. Zeta Producer 17.2.4 vollständig neu installieren und normal, nicht ausdrücklich als Administrator, starten.

    Wichtig: Der gelöschte Runtime-Ordner wird nicht allein durch den Programmstart neu aufgebaut, sondern erst durch die Installation wiederhergestellt.

    Falls der Fehler danach weiterhin auftritt, ist Windows 10 selbst sehr wahrscheinlich nicht die Ursache. Der Fehler 0x8007139F kann bei WebView2 auftreten, wenn die DPI-/Skalierungseinstellungen des Hauptprogramms und des WebView2-Prozesses nicht zusammenpassen. Als Ursache kommen insbesondere gespeicherte Windows-Kompatibilitätseinstellungen beziehungsweise eine aktivierte „Hohe DPI“-Skalierungsüberschreibung infrage.

    Diese Einstellungen liegen außerhalb der Zeta-Producer-Ordner und können deshalb sowohl eine Neuinstallation als auch das Umbenennen des kompletten Dokumentenordners überleben.

    Bitte dann bei beiden betroffenen Rechnern Folgendes prüfen:

    1. Im Windows-Explorer diese Datei aufrufen:
    %LOCALAPPDATA%\Zeta Producer 17\Applications\producer.exe
    2. Über Rechtsklick → Eigenschaften → Kompatibilität prüfen:
    - „Programm im Kompatibilitätsmodus ausführen“ muss deaktiviert sein.
    - Unter „Hohe DPI-Einstellungen ändern“ darf keine Skalierungsüberschreibung aktiviert sein.
    - Bitte dieselben Punkte gegebenenfalls auch unter „Einstellungen für alle Benutzer ändern“ kontrollieren.
    3. Dieselbe Prüfung für diese Datei durchführen:
    %LOCALAPPDATA%\Zeta Producer 17\Applications\WebView2\msedgewebview2.exe
    4. Windows neu starten und Zeta Producer anschließend normal starten.

    Bitte gebt uns anschließend kurz Rückmeldung, ob die saubere Runtime-Neuinstallation geholfen hat beziehungsweise ob bei einer der beiden Dateien eine Kompatibilitäts- oder DPI-Einstellung aktiv war.

    Falls beides ohne Befund bleibt, wäre der nächste Schritt eine gezielte Diagnose der tatsächlich wirksamen AppCompat-, DPI- und WebView2-Einstellungen.

    Wir konnten das Problem inzwischen reproduzieren und die Ursache eingrenzen. Kurz erklärt:

    OneDrive (und auch Dropbox) speichern Dateien standardmäßig als sogenannte Platzhalter – die Datei ist im Explorer sichtbar, der Inhalt liegt aber unter Umständen nur in der Cloud („online-only"). Windows macht das automatisch, z. B. über „Speicherplatz freigeben" bzw. die Speicheroptimierung, ohne dass man etwas davon merkt.

    Beim Aufruf der Vorschau muss der interne Webserver von Zeta Producer diese Dateien lesen. Normalerweise lädt OneDrive den Inhalt dann automatisch nach. Wenn die Synchronisierung aber gerade pausiert oder gestört ist (oder OneDrive nicht angemeldet ist), schlägt das Nachladen fehl – und es erscheint genau die gemeldete Fehlermeldung („Failed opening required …"), obwohl die Datei scheinbar vorhanden ist. Deshalb tritt der Fehler auch nur „manchmal" auf und verschwindet, wenn man das Projekt aus dem Cloud-Ordner heraus- und wieder hineinschiebt.

    Workaround (sofort möglich):

    1. Im Windows Explorer mit der rechten Maustaste auf den Projektordner klicken
    2. „Immer auf diesem Gerät behalten" aktivieren (bei Dropbox: „Offline verfügbar machen")
    3. Zusätzlich prüfen, dass die OneDrive-/Dropbox-Synchronisierung läuft und nicht pausiert ist

    Damit bleiben die Projektdateien dauerhaft physisch auf dem Rechner und die Vorschau funktioniert zuverlässig. Alternativ kann das Projekt auch außerhalb des Cloud-Ordners abgelegt werden.

    Dauerhafte Lösung:

    Wir arbeiten bereits an einem Fix, mit dem Zeta Producer solche Cloud-Ordner automatisch erkennt und die Vorschau davon unabhängig macht – der Workaround ist dann nicht mehr nötig. Er wird in einem der nächsten Updates enthalten sein.

    Danke an alle für die Meldungen und die Geduld!

    Noch ein Hinweis/Tipp:

    Zitat

    When TLS 1.3 is enabled, a new asynchronous TLS 1.2 core is used as well. Should this cause any problems in compatibility or performance, disabling TLS 1.3 will revert to the old TLS 1.2 core as well.

    Das schreibt der Hersteller unserer Publishing-Komponente (Rebex).

    Es wäre also bei Problemfällen einen Versuch wert, nur TLS 1.2 zu aktivieren.

    Die Meldung sieht danach aus, dass in Ihrem Projekt eine lokale Layout-Variante unvollständig ist. Der Temp-Ordner ist nur der Arbeitsordner des Layout-Designers; die fehlende Datei wird beim Start erneut aus dem Projekt dorthin kopiert.

    Bitte schließen Sie Zeta Producer, erstellen Sie zur Sicherheit eine Sicherung des Projektordners und prüfen Sie dann diesen Ordner:

    D:\Dokumente\Zeta Producer 17\Projects\GV Busenbach\layouts\Campfire Responsive\variants\anderer\

    Dort fehlt vermutlich die Datei values.json. Falls Sie eine Projektsicherung haben, können Sie diese Datei bzw. den ganzen Variantenordner anderer daraus wiederherstellen. Alternativ können Sie den Ordner anderer testweise umbenennen oder aus dem Projekt herausnehmen; Zeta Producer sollte dann wieder auf eine vorhandene Variante zurückfallen bzw. eine andere Variante auswählbar machen.

    Danke, CKV, kannst Du ggf. die anderen Meldungen in der Liste in der Mitte oben (also unterhalb des selektierten PHP-Eintrags) ggf. auch noch als Screenshots posten?

    Oben ist der neueste, weiter unten die früheren.

    Oft ist der erste solcher Fehler entscheidend, und die weiteren sind Folgefehler.

    Das könnte auch sein, Phil, stimmt.

    Die Suchreihenfolge von einer DLL ist unter Windows normalerweise:

    1. Verzeichnis der ausführbaren Datei (php.exe).
    2. Systemverzeichnisse (C:\Windows\System32, etc.).
    3. PATH-Variable.

    Wir liefern die "libssh2.dll" direkt im Verzeichnis von PHP.exe mit. Aus irgend einem Grund funktioniert das hier aber offensichtlich nicht.

    Andererseits wird bei uns PHP indirekt über Apache aufgerufen, und es könnte dann ggf. doch sein, dass er zuerst im Apache-Ordner sucht. Dort liegt auch eine libssh2.dll.

    Insgesamt also für mich verwirrender denn je. 😐

    Danke für ausprobieren; falls es Dein System zulässt, fände ich es noch einen Versuch wert, das optionale Feature "OpenSSH" über das Windows-Setup zu deinstallieren.

    Falls das das Issue behebt, können wir hier im Anschluss versuchen, das nachzustellen und einen Workaround zu finden, der diese Schritte nicht mehr notwendig macht.

    Hier eine Schritt-für-Schritt-Anleitung:

    Anleitung: OpenSSH Feature deinstallieren

    1. Einstellungen öffnen

    • Klicke auf das Startmenü (Windows-Symbol links unten).
    • Tippe "Einstellungen" ein und öffne die App.

    2. Apps & Features öffnen

    • Wähle den Menüpunkt "Apps".
    • Klicke dann links auf "Optionale Features".

    3. OpenSSH suchen

    • Im Bereich "Installierte Features" nach unten scrollen.
    • Suche nach:
      • "OpenSSH-Client"
      • und/oder "OpenSSH-Server".

    4. Deinstallieren

    • Klicke auf den Eintrag "OpenSSH-Client" (oder "OpenSSH-Server").
    • Es erscheint die Schaltfläche "Deinstallieren" → darauf klicken.
    • Wiederhole das ggf. auch für den anderen Eintrag, falls beide installiert sind.

    5. Neustart des PCs (empfohlen)

    • Nach der Deinstallation am besten den PC einmal neu starten, damit alle Änderungen wirksam werden.

    Wenn ich raten müsste, würde ich auf "C:\WINDOWS\System32\OpenSSH\" als Ursache tippen.

    Könntest Du mal temporär diesen Eintrag aus PATH herausnehmen? (Neu an Windows anmelden danach, damit das wirksam wird).

    Nachfolgend eine Erklärung (via ChatGPT), um den Eintrag zu entfernen.

    Anleitung: OpenSSH aus der PATH-Variable entfernen (Windows 10/11)

    🟢 Vorbereitung

    • Sie benötigen Administratorrechte, falls der Eintrag im System-PATH gespeichert ist.
    • Falls der Eintrag nur im Benutzer-PATH steht, reichen normale Benutzerrechte.

    🥇 Schritt 1: Umgebungsvariablen öffnen

    1. Klicken Sie mit der rechten Maustaste auf das Windows-Startsymbol.
    2. Wählen Sie „System“ (oder „Systemsteuerung“ > „System“).
    3. Klicken Sie rechts auf „Erweiterte Systemeinstellungen“.
    4. Im Fenster „Systemeigenschaften“ klicken Sie unten auf den Button „Umgebungsvariablen…“.

    🥈 Schritt 2: PATH-Einträge bearbeiten

    1. Es öffnet sich das Fenster „Umgebungsvariablen“.
    2. Oben sehen Sie die „Benutzervariablen“ (nur für Ihr Konto).
    3. Unten sehen Sie die „Systemvariablen“ (für alle Benutzer).

    ➤ Benutzer-PATH bearbeiten:

    1. Suchen Sie in den Benutzervariablen den Eintrag mit dem Namen „Path“.
    2. Markieren Sie ihn und klicken Sie auf „Bearbeiten…“.

    ➤ System-PATH bearbeiten:

    1. Suchen Sie in den Systemvariablen den Eintrag „Path“.
    2. Markieren Sie ihn und klicken Sie auf „Bearbeiten…“.

    🥉 Schritt 3: OpenSSH-Eintrag entfernen

    1. Im Fenster „Umgebungsvariable bearbeiten“ sehen Sie eine Liste mit einzelnen Zeilen.
    2. Suchen Sie nach einem Eintrag:

      Code
      C:\WINDOWS\System32\OpenSSH\ 
    3. Markieren Sie diesen Eintrag.
    4. Klicken Sie auf „Löschen“.
    5. Bestätigen Sie mit „OK“.

    🏁 Schritt 4: Änderungen übernehmen

    1. Schließen Sie alle offenen Fenster mit „OK“.
    2. Starten Sie Programme oder die Kommandozeile neu, damit die Änderung wirksam wird.

    📝 Hinweis

    • Wenn der Eintrag nur im Benutzer-PATH stand, war keine Administrator-Berechtigung nötig.
    • Wenn er im System-PATH war, war ggf. eine Admin-Bestätigung (UAC) erforderlich.

    Meine Vermutung ist, dass irgend etwas am System die libssh2 ausgetauscht/gehijackt hat, die unser lokaler PHP-Interpreter nutzt.

    Ich glaube phil-web hatte das bei sich auch, und konnte es dann in einer neuen VM nicht mehr nachstellen.

    Unser PHP bringt lokal eine "libssh2.dll" mit.

    Also entweder wurde diese ersetzt, oder eine davon abhängende Systemkomponente ersetzt, oder ggf. wurde auch unsere lokale "libssh2.dll" (ggf. durch PATH- oder andere Umgebungsvariablen?) außer Funktion gesetzt.

    Ich will nur mal anmerken, dass Länderflaggen als Sprachindikator ein klassischer UX-Fehler ist.

    Während es üblich ist, dass ein Land eine einzige Amtssprache besitzt, so ist es doch alles andere als eindeutig. Z. B.:

    • Schweiz hat mehrere Sprachen wie DE, IT, FR.
    • Österreich hat DE als Sprache. Müssen Österreicher also auf die DE-Flagge klicken?
    • Kanada hat EN und FR.
    • Nimmt man Großbritannien als Flagge für EN? Oder die Flagge der USA als Indikator für EN?
    • usw.

    Aus meiner Sicht gehört da die Sprache als Name rein (z. B. in der nativen Sprache geschrieben), ggf. noch das Kürzel wie DE und EN, aber eben keine Flaggen.

    Beim Aufruf des Layoutdesigners kommt eine Fehlermeldung (siehe Upload) die ein Fortsetzen der Bearbeitung verhindert. Das gilt leider für alle meine Webseiten mit unterschiedlichen Layoutvorlagen. Im Anhang die Fehlermeldung aus dem Layout "Stripe Responsive".

    Layoutdesigner sollte in dieser Vorabversion jetzt auch korrigiert sein:

    Datei downloaden
    zp16-setup.exe, 413,2 MB
    qu.zeta-software.de

    Danke fürs Testen!

    Danke, EBKS, das muss definitive die falsche Version sein.

    In Deinem Event-Log-Auszug wird von .NET "8.0.1325.6609" gesprochen, wir haben den obigen Download aber mit .NET 9 ausgeliefert.

    Das ist der Download:

    [entfernt wegen neuerer Version]

    Ich verstehe noch nicht ganz den Grund, aber aus meiner Sicht ist der von Dir berichtete Fehler so eigentlich nicht möglich.