Beiträge von Thomas W.

Hallo,

ich hatte in der Version 12.5.7 schon einmal mit diversen Responsive Designs, vorzugsweise mit Fotos über die gesamte Seitenbreite, herumprobiert und musste diese Entwürfe leider immer verwerfen, da die Dropdown-Menüs nicht auf großen iPads funktionierten.

Ich hatte nun die Hoffnung, dass mit ZETA 13 auch diese Dropdown-Menüs angepasst worden sind, was leider nicht der Fall ist.

Es geht um folgende Layouts:

Contemporary Responsive
Panorama Responsive
Poster Responsive
Producer Responsive
Stripe Responsive

Insofern ich hier Hauptmenü-Einträge und Untermenü-Einträge habe, werden diese auf dem PC mittels des Hover-Effekts aufgeblendet und ich klicke dann mit der Maus auf den Untermenü-Eintrag. Alles schön.

Beim iPad führt ein Touch auf den Hauptmenü-Eintrag dazu, dass das Dropdown-Menü ganz kurz aufklappt, dann aber zusätzlich als erneutes Touch-Event ausgewertet und als Auswahl-Klick auf den Hauptmenü-Eintrag behandelt wird, was dazu führt, dass das Dropdown-Menü sofort wieder zuklappt. Somit ist auf einem iPad eine Auswahl von einem Untermenüpunkt leider überhaupt nicht möglich, da das Dropdown-Menü maximal 0,5 bis 1 Sekunde aufbleibt.

Dass dieses auch anders geht, kann man in den folgenden Layouts sehen:

Smart Responsive
Travel Responsive
Clean Style Responsive

Dort wertet das iPad den ersten Touch auf den Hauptmenüeintrag korrekt nur einmal aus, klappt dann das Dropdown-Menü aus und wartet darauf, dass man einen Untermenüpunkt mit einem erneuten Klick auswählt. Genau so muss es sein, da die Menüs ansonsten nicht per iPad bedienbar sind.

Es geht mir nicht um das Design der Buttons oder der Schaltflächen, das kann ich ggf. jederzeit im CSS-Code ändern.

Es müsste sicherlich irgendwo ein jscript-Code eingefügt werden, der die Touch-Events anders auswertet, so wie bei den zuletzt genannten Layouts.

Gibt es dafür einen Codeschnipsel, den ich als Quelltext oder über eine .js Datei einfügen kann, so dass ich die fehlerhafte Dropdown-Funktion der Layouts anpassen kann? Oder was kann ich ansonsten wo ändern, damit die Dropdown-Menüs offen bleiben? Hat da jemand einen Lösungsvorschlag?

Vielen Dank.

Hallo liebes Forum,

da ich zum einen mit ZETA (aktuellste Version) an meinem PC zuhause und an meinem Notebook unterwegs arbeite, habe ich mein Homepage-Projekt in meiner Dropbox abgelegt.

Da ich immer nur (abwechselnd) von einem Gerät an meinem Projekt arbeite, funktioniert dieses wunderbar, es gibt keine Konflikte und die Daten sind immer synchron und aktuell.

Jetzt habe ich mir nähere Gedanken zur Datensicherheit bezüglich Dropbox und der Zugriffsmöglichkeit durch Dritte auf meine Daten gemacht und aus diesem Grund Boxcryptor installiert und damit meine Dropbox komplett direkt auf meinem Endgerät verschlüsselt, so dass in die Dropbox nur noch verschlüsselte Daten synchronisiert werden. Boxcryptor legt dabei ein virtuelles, verschlüsseltes Laufwerk an, vergibt diesem einen Laufwerksbuchstaben und managt dann den verschlüsselten Datenverkehr mit der Dropbox.

Mit allen meinen Dokumenten, Bildern, Zeichnungen, egal was, funktioniert diese Verschlüsselung und der Zugriff auf die Daten einwandfrei...... Leider nicht mit den Projekten von ZETA.

Ich kann zwar alle Einzeldaten, alle HTML-Codes, alle Bilder usw. der Projekte voll entschlüsselt sehen, bearbeiten und anzeigen lassen, nur wenn ich die Projektdatei von ZETA zur Bearbeitung öffne, erscheint die Meldung: Vorlagendatei "default.html.*" wurde nicht gefunden. (siehe Bild)

Ich habe den gleichen Projektordner lokal probiert (alles läuft), dann auf einem Netzlaufwerk mit einem Laufwerksbuchstaben (alles läuft), dann in der unverschlüsselten Dropbox (alles läuft) und ZETA öffnet das Projekt einwandfrei zur Bearbeitung. Kopiere ich exakt diesen Projektordner in das virtuelle Laufwerk von Boxcryptor, dann kommt die Fehlermeldung wie im Bild. Kopiere ich exakt diesen Ordner von Boxcryptor wieder auf meine lokale Platte zurück, läuft alles wieder. Kopierfehler/Verschlüsselungsfehler sind somit ausgeschlossen.

Es scheint, als ob ZETA mit dem virtuellen Laufwerksbuchstaben nicht zurechtkommt und höchstwahrscheinlich auf dem virtuellen Laufwerk auch die default.html sucht, anstatt diese Datei vom lokalen Programm-Speicherplatz zu integrieren? Da die default.html in jedem Fall lokal abgespeichert und damit unverschlüsselt ist, müsste man einen Verschlüsselungsdefekt von Boxcryptor eigentlich ausschließen können. Evtl. gibt es das Problem auch nur, da es sich um ein virtuelles Laufwerk und keine physische Laufwerksverbindung handelt?

Vielleicht hat irgendjemand dieses oder ein ähnliches Problem auch schon einmal gehabt oder vielleicht ist im ZETA-Code irgendeine dynamische Ortsangabe anpassbar, so dass die default.html und ggf. andere Dateien fix am richtigen Ort gefunden werden?

Über Anregungen und Ideen würde ich mich sehr freuen.

Vielen Dank im Voraus.

Es läuft !!!!

Super Idee, alles ins CSS der Hauptseite einzufügen. An diese Lösung habe ich einfach nicht gedacht....

Tausend Dank an das Forum für die schnelle Hilfe.

Da man die ZETA-Arbeitsfläche nicht online sehen kann, habe ich jetzt mal zwei Bildschirmkopien erstellt und angefügt. Da sieht man das Problem wirklich besser als per Text-Beschreibung.

Das erste File "Formular-im Browser-und-nicht-responsive" zeigt die Darstellung im Vorschau-/Livebetrieb des Browsers. Abgeschnittene Felder rechts und eigentlich ein vierseitiger Rahmen.

Im ZETA-Arbeitsbereich, wird alles wie in der Datei "Formular-in ZETA-anderes-Design" angezeigt, da ich die form.css des Formular-Widgets entsprechend verändert habe.

Eigentlich müsste ZETA den Inhalt von der Arbeitsfläche mit dem veränderten Design umsetzen, tut das aber leider nicht, sondern stellt irgendeinen Standard bei der Umsetzung ein.

Ich hoffe, das hilft weiter?

Als Ergänzung hier noch der CSS-Code aus der neuen form.css des Formular-Widgets. Ergänzt/angepasst wurden die Angaben zu border-style/ border-color und border-width

.zp-form input.typetext, .zp-form input[type="text"], .zp-form input[type="number"], .zp-form input[type="email"], .zp-form input[type="tel"], .zp-form input[type="url"], .zp-form input[type="date"], .zp-form input[type="time"], .zp-form input[type="color"], .zp-form input[type="search"], .zp-form textarea{
font-family: inherit;
font-size: inherit;
color: #333333;
background: #ffffff;
padding: 6px 8px;
border-style: solid;
border-color: #1f8ac7;
border-width: 0px 0px 1px 1px;
max-width: 100%;
}

Hallo,

für ein Projekt setze ich das Layout "Square Responsive" ein und habe auf einer zweispaltigen Seite in einer Spalte ein Formular erstellt.

Ich möchte die Formularfelder stets mit Rahmen über die gesamte Spaltenbreite ausgefüllt haben. Egal, was ich aber an Pixelbreiten eingebe und versuche anzupassen, es werden immer die rechten Rahmen abgeschnitten, da das Formular-Widget leider nicht responsive ist.

Ich wollte dieses Problem nun ganz einfach designtechnisch lösen, indem ich das Formular-Widget kopiere und dort das CSS ändere. Dieses habe ich gemacht und im form.css des kopierten Formular-Widgets dann einfach die obere und die rechte Rahmenstärke auf 0 gesetzt. Damit ist es dann optisch egal, ob die Felder abgeschnitten werden oder nicht, da es sich um ein "offenes" Felddesign handelt.

Das funktioniert tadellos im ZETA in der Bearbeitungsansicht. Dort sieht man wunderbar die gemachten Änderungen. Alles funktioniert.

Sowie ich mir das Projekt aber in der Browser-Vorschau (egal welcher) anschaue oder auch im Live-Betrieb, werden die Änderungen am Formular-Widget form.css anscheinend nicht übernommen oder bei der Seitenerstellung von ZETA intern überschrieben und es werden wieder die Original-Eingabefelder mit abgeschnittenem, vierseitigem Rahmen dargestellt. Im ZETA ist aber nach wie vor alles zweiseitig und OK, auch !important hinter den Einträgen funktioniert leider nicht.

Es muss also noch irgendein anderes File existieren, in dem die class "zp-form" verändert werden muss oder es gibt einen Fehler bei der internen Seitenerstellung.....?

Hat da jemand eine Idee, wo ich ggf. noch was zusätzlich ändern muss?

Vielen Dank für die Hilfe.