Beiträge von Hanabi

    Hallo Maik,

    bei Änderungen an der Webadresse sollte ausnahmsweise die Veröffentlichung wie folgt vorgenommen werden:

    • erweitert - > erstellen - > alle Seiten erstellen
    • veröffentlichen - > komplette Website veröffentlichen

    Hallo Maik,

    der inkognito-Modus dient eigentlich nur dazu, mit einem leeren Cache und ohne Browserverlauf die Seite aufzurufen. Ich vermute, dass ihr im normalen Browserfenster noch die im Cache vorhandene Version der Seite angezeigt wurde.

    Hallo Nemessis,

    Bei einer Deinstallation bleibt der Ordner /settings unter dokumente/zeta producer.../ erhalten, diesen einfach umbenennen in "settings-alt" und Zeta neu starten, um die Standardeinstellungen wiederherzustellen (Achtung, Lizenz muss danach neu eingetragen werden)

    Wenn das nicht hilft, zunächst rekapitulieren, ob der Fehler in Zusammenhang mit einem Windows-Update aufgetreten ist.

    als dritte Möglichkeit hier im Forum nach "Workaround für langsamen Zeta Producer" suchen.

    OK, ich habe jetzt mal eine Testbestellung bis zum Ende durchlaufen lassen, also diesen Kalender bitte nicht ausliefern :-). Auf dem Server und mit dem Projekt scheint somit alles in Ordnung, der Fehler tatsächlich nur auf dem PC zu liegen.

    Hier zunächst der wahrscheinlichste Ansatz:

    • Beende Zeta, suche dann im Windows Explorer unter "Dokumente" das Verzeichnis "Zeta Producer 14"
    • Benenne dort den Ordner "Settings" in "settings-alt" um
    • Starte Zeta neu
    • Wenn der Fehler durch falsche Einstellungen in den Settings verursacht wurde, führt das Umbenennen des Ordners dazu, dass ein neuer Ordner "Settings" mit den Standardeinstellungen angelegt wird.
    • ACHTUNG: Die Lizenznummer muss danach neu eingegeben werden

    Weitere Möglichkeiten wären:

    • Internet Explorer auf Standardeinstellungen zurücksetzen (dessen Engine wird von Zeta für die Darstellung im Programm benutzt)
    • Virenscanner ausschalten
    • prüfen, ob zwischen dem Fehler und neu installierter Software ein Zusammenhang besteht (kann auch zutreffen mit Microsoft Update)

    Hallo Jörg,

    ich habe das jetzt mal nachgebaut mit Flat Responsive (als neues Projekt angelegt).

    Test 1:

    Test 2:

    Test 3:

    • In den Layouteigenschaften das Hauptmenü auf "scrollend ja" gesetzt
    • veröffentlicht unter https://flat-fixiert-3.zeta-producer.com/index.html
    • ERGEBNIS: Navigationsmenü manuell ist oben im Bannerbereich fixiert und wird beim Scrollen nur im Bereich des Hauptmenüs kurzzeitig verdeckt, ist aber beim weiteren Runterscrollen dauerhaft sichtbar.

    Wenn ich jetzt das Navi-manuell in den Bannerbereich verschiebe, scrollt es mit, obwohl weiterhin "fixiert" markiert ist. Das wäre jetzt eigentlich meine Idee gewesen, im Bannerbereich über dem Navi-manuell noch 2 Spacer einzufügen, um das Navi-manuell unter das Hauptmenü zu drücken, funktioniert so aber nicht.

    Wenn es das Navi-manuell sein soll, scheint es nur wie in Test 3 dargestellt zu funktionieren. Alternativ könntest Du noch ein "Infobanner" zweckentfremden und dieses entweder oben oder unten platzieren. Oder Du schaust mal bei Mario vorbei, ob der da nicht was in Petto hat.

    Hallo Pete,

    einfach in der robots.txt folgendes eintragen:

    Code
    User-agent: *
    Disallow: /kontaktformular.php

    Zusätzlich solltest Du alle Links, die auf das Formular führen, mit "nofollow" kennzeichnen.

    Durch den Eintrag in der robots.txt wird für alle Crawler verboten, die kontaktformular.php zu indizieren. Über das "nofollow" in der Verlinkung wird sichergestellt, dass Suchmaschinencrawler dem Link nicht folgen und dadurch versehentlich das Kontaktformular indizieren. Außerdem verhindert dies Fehlermeldungen, wenn beispielsweise Google einem Link folgt, der grundsätzlich erlaubt wäre (kein Häkchen bei "nofollow"), dann aber im Abgleich mit der robots.txt feststellt, dass die Seite doch nicht indiziert werden soll.

    Heute ist die Antwort von Google gekommen, die ist allerdings genauso allgemein gehalten, wie hier bereits unter #2 dargestellt. Jetzt kommt also das Ausschlussverfahren: Bei Aufruf der Google Webfonts die privacy angeklickt und darin keine besondere Regel gefunden. Im Klartext, auch die Webfonts werden jetzt über Irland abgewickelt.

    Hallo Roland,

    auf die Schnelle 3 Antworten zu Deinen Fragen:

    1. Bei Top Responsive ist das Logo neben dem Menü platziert. Wenn man jetzt noch Name + Slogan unterbringen wollte, wäre dies nur über dem Menü möglich. Das Top-Responsive ist stark auf optische Reize ausgerichtet (Schräge Kanten, Einrollen), und damit anders als die weitestgehend "technischen" Layouts.
    2. Eine Anpassung wäre theoretisch möglich über den Weg der Erstellung eines eigenen Layouts (https://developer.zeta-producer.com/layouts.html).
    3. kommt darauf an, was Du unter adäquat verstehst. Ein zweites Layout mit schräg verlaufender Top-Line gibt es nicht, Layouts mit horizontalem Menü, Logo UND Name UND Slogan hingegen mehrere (z. b. Simple Responsive)

    Hallo Gieri,

    wenn Dir der Datenschutz eh egal ist, warum fragst Du dann danach? Bette den Google-Kalender einfach ein und fertig. Alternativ einfach einen Link zum Google Kalender einstellen, der Link funktioniert ohne Cookies und erhöht die Performance Deiner Seite, da keine Daten vom externen Server geladen werden müssen.

    Ansonsten kann man den Kalender auch auf einer Seite mit "geschütztem Bereich" präsentieren und diesen Bereich "Google-Kalender mit Datenübertragung an Dritte" benennen.

    Es geht hierbei nicht darum, die Daten im Kalender zu schützen, sondern den Besucher davor zu schützen, dass bereits der Besuch Deiner Seite mit Kalender für die Erstellung eines Besucherprofiles genutzt wird. Ausführlich ist diese Thematik unter https://kola.opus.hbz-nrw.de/opus45-kola/fr…helorarbeit.pdf betrachtet worden, auf Seite 18 findet sich hierzu auch eine Grafik, die dies verdeutlicht.

    Hallo Stefan,

    willkommen im Forum,

    bitte beschreibe Dein Problem etwas genauer nach nachfolgendem Schema:

    ob man etwas wegen Datenschutz beachten muss

    Hallo MaGie ,

    datenschutztechnisch ist es so, dass mit Aufruf der Seite, die den Google Kalender enthält, die IP-Adresse des Besuchers an Google übermittelt wird. Diese ist ein personenbezogenes Datum, also muss entweder berechtigtes Interesse des Seitenbetreibers oder aber eine Einwilligung des Besuchers vorliegen. Das berechtigte Interesse des Seitenbetreibers sehe ich durchaus als gegeben, da die Übermittlung der IP-Adresse technisch notwendig ist, um den Kalender anzuzeigen. Leider beschränkt sich Google aber nicht auf das technisch Notwendige, sondern legt neben Sitzungscookies auch noch diverse andere Cookies auf dem Rechner des Besuchers ab. Diese werden nach Ende der Sitzung nicht automatisch gelöscht, sondern verbleiben für eine unterschiedliche Dauer auf dem Rechner des Besuchers. Nach meiner Auffassung ist damit die Grenze des berechtigten Interesse überschritten, so dass mit einer Einwilligung gearbeitet werden muss.

    Lösungsansatz:

    • Der Kalender wird auf einer separaten Seite platziert
    • die Seite wird aus dem Menü ausgeblendet, damit ist diese aus dem Menü heraus nicht direkt aufrufbar
    • In den Seiteneigenschaften für die Kalenderseite unter "Google" das Häkchen bei "in Sitemap aufnehmen" entfernen. Damit wird die Seite nicht in die Sitemap aufgenommen
    • Auf einer Seite der normalen Homepage legst Du einen neuen Textartikel an, darin bringst Du eine Belehrung zur Datenübermittlung an Google sowie die Speicherung von Cookies unter.
    • Unter diesen Artikel platzierst Du einen Button "Ich willige ein und möchte den Google Kalender sehen". Diesen Button verlinkst Du mit der Kalenderseite. Der Link wird als "nofollow" für Google gekennzeichnet, damit folgt Google diesem Link nicht und nimmt den Kalender nicht in die Suchergebnisse auf. Anderenfalls könnte es passieren, dass ein Besucher über die Google-Suche direkt auf Deine Seite kommt, ohne die Belehrung gelesen und seine Einwilligung erklärt zu haben.
    • In der robots.txt fügst Du für die Kalenderseite noch ein disallow ein

    Damit sollte nach meiner Ansicht dem Datenschutz genüge getan sein.

    Hallo Berhard,

    das Widget "geschützter Bereich" verwende ich nur für Protokolle von Mitgliederversammlungen oder interne Fotos von Veranstaltungen. Da es dabei nur um Lesezugriffe handelt, gibt es nur ein für alle Mitglieder einheitliches Kennwort (Bereich Protokolle) und für jede Veranstaltung einen eigenen geschützten Bereich mi jeweils eigenem Kennwort.

    Da es bei der von Dir genannten Menge an Mitgliedern sicherlich auch um das eigenständige Pflegen der Kontaktdaten geht, solltest Du mal einen Blick auf http://www.admidio.org werfen.

    Admidio wird auf dem eigenen Server installiert und benötigt PHP und MySQL oder MariaDb. Den Abgriff von Daten aus einer MySQL-Datenbank hattest Du glaube ich, schon mal bei den Elektroingenieuren realisiert. Zu Admidio gibt es auf der Webseite auch eine Demo. Das Projekt ist Open-source, für Fragen steht ein Forum zur Verfügung.

    Admidio kann auch in die eigene Homepage eingebunden werden. habe ich aber nicht gemacht, da wir unsere Admidio-Installation als reine Vereinsverwaltung (Zugriff nur Vorstand, Buchhaltung und Mitgliederverwaltung) nutzen und deshalb komplett von der öffentlichen Homepage entkoppelt haben.

    Lösungsvorschlag:

    • auf Seite B ein Bilderalbum mit mehreren Bildern anlegen
    • auf Seite A ein einzelnes Bild anlegen, dort in den Eigenschaften die Klickadresse festlegen, diese verweist dann auf das Album auf Seite B
    • wenn jetzt auf Seite A das einzelne Bild angeklickt wird, öffnet sich Seite B mit dem Album

    Hallo Gerhard,

    eventuell bekommen wir das sogar noch selbst auf die Reihe, ich fasse nur mal kurz zusammen, was wir bisher zu PHP auf dem Server haben:

    1. Unter https://www.webcorner.de/assets/php/for…zp-php-info.php wird eine aktivierte PHP-Version (5.4) angezeigt.
    2. Diese ist "end of live", also ohne laufenden Support und auch ohne Sicherheitssupport.
    3. Die "Phar"-Unterstützung ist aber für diese Version aktiviert (siehe Abschnitt PHAR in der Info).

    Der Shop ist ausgerichtet auf PHP 7, aktuell sind hierbei die 7.2 (empfohlen) oder 7.3 (stable). Ich würde als nächsten Schritt im DF-Control-Center von PHP 5.4 auf PHP 7.2 wechseln. Danach erneut testen, eventuell ist das Problem damit schon behoben.

    Zweiter "Störenfried" könnte die Veröffentlichung in einem Unterordner der Hauptdomain sein. Ich bin mir bei solchen Versuchsanordnungen immer unsicher, wo die PHP-Version erwartet wird, also ob in webcorner.de oder webcorner.de/alex/. Stressfreier wäre es hier, eine Subdomain zum Testen zu verwenden, also test.webcorner.de und für diese Subdomain im Control-Center die PHP 7.2 zu aktivieren.

    Hallo elsbett ,

    aus meiner Sicht wäre es besser zur Beurteilung der Seite, wenn die "vermutlich strittigen" Inhalte auf der Seite geblieben wären. Der jetzt verbliebene "Restinhalt" bietet keine Gewähr, dass auch nach einer erneuten Freischaltung eine dauerhafte Nutzung ausschließlich "privat" erfolgt. Das macht eine Beurteilung schwierig.

    Nachtrag: Es gibt aber zum Glück ein Gedächtnis im Internet:

    https://web.archive.org/web/2018081218…e.ch/index.html

    https://web.archive.org/web/2018081219…come-dance.html

    https://web.archive.org/web/2018081215…dine-dance.html

    https://web.archive.org/web/2018081210…eens-dance.html

    Also bitte nochmal drüber nachdenken, ob dies noch eine rein private Nutzung ist.

    Hallo Stefan,

    beim Konvertieren eines Projektes aus V13 mit Shop werden alle in diesem Projekt genutzten Wigdets aus dem Shopbereich übernommen und können auch unter V14 für dieses Projekt weiter genutzt werden. Das Einfügen über "Widget" ist aber nach meiner Kenntnis nicht möglich, sondern nur das Kopieren eines vorhandenen Artikels. Wenn Du also einen vorhandenen Shop von V13 in V14 fortführen willst, lege Dir zunächst in V13 eine deaktivierte Seite "Ablagen - Vorlagen - Widgets" an, auf der Du alle für den Shop erforderlichen Widgets einmal ablegst. Im konvertierten Projekt in V14 kannst Du kann von dort aus das Widget kopieren und auf der richtigen Seite einfügen.

    Hallo Frank,

    beim ersten Problem habe ich keine Lösung, da es sich bei Wurstholz "mit Text" um ein Unikat handelt.Persönlich finde ich das auch gar nicht so schlimm, die Sonderwünsche am Ende der Bestellung aufzunehmen, es würde sich dann anbieten, den Standardtext im Bestellformular zu ändern:

    -> "Shop" ->"Texte" -> "Textanpassungen": Dort die "Bezeichnung Nachricht optional" ändern in "Textprägungen und optionale Nachrichten"


    Den Mindestbestellwert solltest Du über die "Versandarten" regulieren können, indem Du innerhalb der Versandart einen neuen "preisbasierten Bereich" anlegst. Diesen nennst Du "Mindestbestellwert nicht erreicht", legst eine Spanne von 0,00 Chf bis 49,99 Chf fest bei Versandkosten von 50,00 Chf.

    Danach legst Du einen zweiten preisbasierten Bereich "Standardversand" mit der Preisspanne 50,00 Chf bis 999999,99 Chf an mit den normalen Versandkosten von 5,99 Chf.

    Wenn jetzt jemand bestellt, bekommt er im ersten Fall (Bestelllwert nicht erreicht) das Bild 1 zu sehen, ansonsten Bild 2. (Nicht wundern, bei unserem Vereinsshop gibt es nur Abholung.)

    Hallo Steini,

    habe eben mal auf einer unserer Seiten mit mehreren Unterseiten nachgebaut und kann das Verhalten bei Dir nicht nachvollziehen. Das Untermenü auf der Hauptseite listet alle Unterseiten in richtiger Reihenfolge auf. Wenn ich eine der Unterseiten weiter nach oben verschiebe, ändert sich sofort auch das Untermenü. Die Seite scheint ja noch nicht online zu sein, unter http://www.tsrs.biz ist noch ein anderes CMS zu sehen.

    Du kannst ja mal die Vorschau öffnen und über die Entwickler-Console (Chrome Mausklick rechts -> "untersuchen", Internet Explorer Mausklick rechts -> "Element untersuchen" schauen, ob dort irgendwelche Fehler (rot) oder Warnungen (gelb) angezeigt werden.

    Hast Du irgendwo auf der Seite eigenes CSS oder eigenen Quellcode hinzugefügt? Falls ja, bitte mal deaktivieren.

    Schreibe bite auch mal, welche Version Du nutzt, ich habe das jetzt gerade unter der 14.3.3 getestet.

    Hallo Sammy,

    das Script, welches Du in Zeta über das Widget "Quelltext" eingebunden hast, enthält nochmals <head> & </head> , nach meiner Ansicht darf head nur einmal je Seite verwendet werden. Innerhalb des head befinden sich Anweisungen für die fancybox, die eventuell mit den globalen Einstellungen kollidieren. Nimm mal probehalber den gesamten head-Abschnitt raus.

    Hallo BS Troisdorf ,

    zunächst sehe ich das Problem, dass die Seite, die die Einzelveranstaltungen enthalten soll, nicht veröffentlicht ist. Dies führt dazu, dass alle in der Veranstaltungsübersicht aufgelisteten Termine auf die Seite "Seite nicht gefunden" verweisen.

    Vermutlich ist die Seite in Zeta deaktiviert. Bitte die Seite "Termine" aktivieren und dann erneut veröffentlichen. Falls sich das Problem dadurch noch nicht behebt, bitte einen Screenshot wie folgt machen:

    • Seite "Aktuelles" öffnen
    • Widget "Veranstaltungsübersicht" öffnen
    • auf "Veranstaltungen auswählen" gehen
    • Screenshot des Abschnittes "Filter" machen und hier einstellen.

    Zetahufi hat sich inzwischen bei mir direkt gemeldet, das Projekt befand sich bei ihm auf einem anderen Laufwerk, dort direkt als Projekt abgelegt. Aus dem übermittelten Screenshot lässt sich bereits ersehen, dass eine Überschreitung der Pfadlänge unwahrscheinlich ist.

    Mit "anderes Laufwerk" kann auch ein mit einem Laufwerksbuchstaben verknüpfter Ordner, ein Netzlaufwerk, USB-Stick oder eine USB-Festplatte gemeint sein, da könnte man jetzt noch weiter schwadronieren über die Speichersicherheit auf USB-Sticks oder Zugriffe von Virenscannern oder oder oder. Fakt ist, dass nach Meldungen der User die Nichtveröffentlichung von Bildern wohl vorwiegend Vorschaubilder betrifft, die im Unterverzeichnis /thumbnails liegen.

    Selbsttest: ich habe ein Standardprojekt genommen und in einen Dateipfad verschoben, der selbst 190 Zeichen lang ist. Dazu kommen noch 7 Zeichen für den Dateinamen. Eingefügt wurde aus den Windows-Beispielbildern das chrysanthemen.jpg in ein Bilderalbum mit der Funktion Vorschaubilder. Beim Veröffentlichen wird hierzu eine Datei chysanthemen-large.jpg im Verzeichnis /images sowie eine chrysanthemen-200x150.jpg im Verzeichnis /thumbnails erstellt. Die Pfadlänge für die letzte Datei beträgt 254 Zeichen. Das Projekt wird veröffentlicht unter https://lang-pfad.zeta-producer.com/index.html und alle Bilder auch angezeigt.

    Unter Windows kopiere ich im Ordner Beispielbilder die Datei und benenne sie um in mehr-chrysanthemen.jpg, importiere diese in ein neues Album. Dies klappt völlig problemlos. Beim Veröffentlichen wird mir jedoch ein Fehler angezeigt, dass der angegebene Pfad zu lang ist. Diese Fehlermeldung hätten also auch die betroffenen User bekommen müssen. Im veröffentlichten Projekt ist das Bild nicht enthalten, die Chrome Console zeigt einen entsprechenden Fehler an.

    Ein zu langer Pfad oder Dateiname führt tatsächlich zum beschriebenen Problem, dass Bilder nicht veröffentlicht werden. Programmseitig wird dies jedoch als Fehler ausgewiesen.

    Andere Reproduktionen des Fehlers sind nicht möglich, weil die genauen Umgebungsbedingungen nicht bekannt sind.

    Hallo Samson,

    vermutlich stand im Formular noch etwas mit oid://. Das ist die Systemvorgabe von Zeta. Mit "oid" wird beim Erstellen der Seite die Webadresse wie in den FTP-Einstellungen angegeben, übernommen. Vermutlich hattest Du zunächst das Formular erstellt und danach die Webadresse geändert. Es kann sein, dass dadurch die Seite "Kontakt" nicht erneut erstellt wurde und deshalb noch der alte Eintrag vorhanden war. Nachfolgende Schritte sollten helfen:

    1. "Veröffentlichen" -> "FTP-Server konfigurieren": Hier prüfen, ob die Adresse in der Form https://www.modellflugplatz.org eingetragen ist, Wenn nicht, bitte ändern.
    2. Mit OK bestätigen
    3. Kontaktseite öffnen -> Formular öffnen -> auf erweiterte Einstellungen (Mischpult) -> "Optionen": Dort bei Erfolgs- und Fehler-URL jeweils hinten auf die Verlinkungen gehen, dort dann auf "Seite" und die passende Erfolgs- und Fehlerseite auswählen.
    4. Mit OK bestätigen

    Im Normalfall sollte dann mit "Veröffentlichen" alles getan sein. Ausnahmsweise machst Du aber diesmal Folgendes:

    1. "Erweitert" -> "Erstellen" ->"Alle Seiten erstellen"
    2. "Veröffentlichen" -> "komplette Website veröffentlichen"

    Hallo Samson,

    gehe im Formular auf das Mischpult unten links, dann auf "Optionen". Dort kannst Du die Erfolgs- und Fehler-URL einstellen.

    Das http://www.bronzenegarde.de und http://www.modellflugplatz.org den selben Inhalt zeigen, scheint es mir so, dass das Projekt ursprünglich als "bronzenegarde" veröffentlicht wurde. Überprüfe hierzu auch noch einmal die FTP-Einstellungen fürs Veröffentlichen. Da beide Seiten mit https beginnen, solltest bei der Webadresse https:// vor die eigentliche Adresse setzen. Momentan steht nichts davor, daher wird die Seite nur mit http statt https veröffentlicht.

    Hallo Alex,

    fängt die Lizenznummer mir ZP12F oder ZP12X an?

    üblicherweise haben wir hier eher den Fall, dass wegen Rechner oder Betriebssystemwechsel eine Lizenz zu häufig aktiviert wurde, was dann zu einer "Home Version" führt.

    • Wenn der Lizenzschlüssel mit ZP12F beginnt, hattest Du den falschen Schlüssel notiert. Dann einfach nochmal nachsehen in der Rechnung, die Du damals per E-Mail bekommen hast.
    • Wenn der Lizenzschlüssel mit ZP12X beginnt, wurde dieser wohl bereits zu oft aktiviert, schicke dann bitte eine E-Mail an support (at) zeta-producer.com, am besten von der Mail-Adresse aus, die auch zum Kauf verwendet wurde.