Beiträge von Hanabi

Zum Beitrag von madas noch folgender Hinweis: Der Originaltext ist bei Landesdatenschutzbeauftragten NRW zu finden. Man beachte hierbei bitte zunächst den ersten Satz und dann die gleich am zweiten Wort angebrachte Fußnote. Die ePrivacy-Verordnung ist bisher nur ein Entwurf und nicht vom europäischen Parlament beschlossen.

Weiterhin sollte man sich die § 12,13 und 15 TMG mal genauer durchlesen. Hier geht es um die Erfassung personenbezogener Daten. Bei einer rechtskonformen Anwendung von Google Analytics werden aber die IP-Adressen soweit verkürzt, dass eine Zuordnung zu einer bestimmten Person gar nicht mehr möglich ist. Es handelt sich bei der IP-Adresse dann nämlich nicht mehr um ein pb Datum.

Relevant ist die Stellungnahme für Webseiten, die Inhalte für registrierte Nutzer bereithalten, wo ich also beispielsweise mich mit einem Kundenkonto anmelden muss. Hier haben wir durch die Anmeldung pb Daten, die der Anbieter mit den eigentlich anonymisierten Trackingdaten ergänzen könnte. In diesem Falle sind dann auch die verkürzten Trackingdaten wiederum pb Daten, weshalb diese erst nach Zustimmung erhoben werden dürfen.

Eine zweite betroffene Gruppe sind alle Seiten mit einem Plugin für soziale Netzwerke, die ungefragt bereits beim Betreten der Seite "nach Hause" telefonieren.

Was jetzt wieder ganz massiv in Erscheinung tritt ist "german Angst" und "vorauseilender Gehorsam".

Ziffer 9 der Liste kannst Du vergessen. Alle bisherigen Strafanzeigen endeten mit entsprechenden Einstellungsverfügungen, weil ein Täter (trotz IP-Adresse) nicht ermittelt werden konnte. In den kommenden Wochen erwarten wir eine weitere Einstellungsverfügung, weil der bloße Versuch des Ausspähens von Daten nicht strafbar ist. Im konkreten Fall wurde versucht, diverse "geschützte Bereiche" aufzurufen trotz entsprechender Verbote in der robots.txt, Nichtaufnahme in die sitemap.xml und Kennzeichnung aller entsprechenden Links als "nofollow".

Hallo Heri,

genau, Inhalte von unsicheren Seiten können nicht in sichere Seiten übernommen werden.

Hallo Rolf,

am besten fängst Du damit an, das Projekt nochmal in der 11-er zu öffnen und durchzugehen, ob irgendwelche Artikel mit Widgets erstellt wurden, die es in der 14 nicht mehr gibt (beispielsweise PopUp-Bild, Laufschrift, Countdown oder Flash-Animation). Diese solltest Du vor einer Konvertierung entfernen, schließt ein paar Störenfriede aus.

Wenn das Projekt in Zeta 14 erfolgreich konvertiert ist, halte dich an die Hinweise unter ZP 14 Konvertiertes Layout Bildergalerie wird falsch dargestellt zum Wechsel auf ein responsive Layout, damit nicht sämtliche Farbeinstellungen verloren gehen. Falls es ein bestimmtes Farbsystem mit nur 3 oder 4 Farben gibt, kannst Du diese auch vorher notieren, ebenso wie die verwendeten Schriftarten und Größen.

Der Aufwand ist überschaubar, wenn Du vorher ausreichend Zeit in die Planung steckst.

Hallo Heri,

Deine eigene Seite ist mit https gesichert, deshalb werden unsichere Inhalte (http://) durch den Browser blockiert, Chrome blockiert komplett, der IE fragt zumindest nochmal nach. Ich habe mal auf http://www.hanabi-pirna.de/test.php zwei Frames eingesetzt, einmal mit https und einmal mit http. Öffne die Seite mal mit Chrome und dann im Vergleich dazu mit dem IE, dann wird das Ganze verständlicher.

PS: Bei uns ist auch eitel Sonnenschein, aber wenn man über Christi Himmelfahrt (in zwei Wochen) wegfahren will, muss man irgendwann vorarbeiten oder zumindest den privaten Schreibtisch vorher mal aufräumen.

Guten Morgen Heri,

überprüfe mal, ob die Seite, die im I-Frame abgebildet wird, mit https:// beginnt und Du die Adresse auch mit https im I-Frame eingegeben hast. Wenn nicht, wird sie als unsichere Verbindung erkannt und deshalb im Browser nicht dargestellt.

PS: neueste Waffe im Kampf gegen Datenklau dürfte ein Verweis auf die EU-Datenschutzgrundverordnung und das darin enthaltene "Recht auf Vergessen" sein. Einfach auf dem geklauten Foto eine Person benennen, die für dieses Foto das "right to forgot" geltend macht und diese Tatsache dem "Dieb" mitteilen. Bei den aktuellen Strafandrohungen sollte dies recht schnell zu einer Entfernung des Bildes führen. (Dies ist einer der Gründe, weshalb ich kein Problem habe, zu einem Event mehrere hundert Fotos zu stellen, selbst wenn ich die Hälfte lösche, bleibt der Informationsgehalt der Seite erhalten).

wie Uwe Keim schon ausgeführt hat, ist der einzig sichere Schutz vor Datenklau die Nichtveröffentlichung. Bei einer gut gepflegten Seite erkennt der Crawler von Google aber meist von selbst Original und Kopie. Wenn man zusätzlich die Bilder vor dem Einlesen in Zeta mit einem Wasserzeichen versieht, lassen sich Löschansprüche zumindest für den Google-Index relativ leicht durchsetzen. Das geklaute Bild ist dann zwar noch immer auf der fremden Webseite vorhanden, wird aber in den Suchergebnissen nicht mehr gelistet.

Bei uns als Verein, der auf Öffentlichkeitsarbeit angewiesen ist, einige ich mich zumeist auf die Formel: "Veröffentlichung mit Quellenangabe und Verlinkung". Dies geht natürlich nur dann, wenn die entsprechenden Fotos oder Texte ein eigenes Werk sind. Bei Berichten zu internationalen Wettkämpfen handhaben wir es im Dachverband so, dass unser Verein mit den Fotografen eine Vereinbarung zur Verwertung trifft, die auf die Urheberrechte des Fotografen verweist, aber auch die Veröffentlichung nicht nur auf unserer Seite, sondern auch auf Seiten anderer Vereine des Dachverbandes (teilweise auch namentlich benannt) unter Quellenangabe ermöglicht.

Ich bin dann auch mal gerne freundlich penetrant und schreibe den entsprechenden Webseitenbetreiber direkt an, wenn ich über die Google-Suche Bilder oder Texte finde, die zwar von unserer Seite stammen, aber denen der entsprechende Quellenlink fehlt. Im Großen und Ganzen kann ich aber bestätigen, dass sich zumindest im Bereich der Vereinswebseiten alle an die von uns bereitgestellten Vorlagen zum Quellenverweis halten.

In Sachen Fotoverwertung bin ich, zugegebenermaßen, ein Rampensau. Wenn es einen Wettkampf gibt, der in eine unserer Sparten passt und ein Fotograf keine weitere Veröffentlichungsplattform hat, bin ich immer bereit, für dieses Material Platz auf unserer Seite einzuräumen. Wenn an Wettkämpfen mit Teilnehmern aus unserem Verein kein eigener Fotograf dabei ist, aber die Fotografen anderer Vereine gute Bilder gemacht haben, werden die so lange bekniet, bis ein Bild für unsere Seite raus springt.

Solange die Urheberrechte für Bild oder Text beim Verein/Seitenbetreiber liegen, halte ich es immer für angemessen, das Ganze über entsprechende Quellenverlinkung zu klären. Bei Urheberrechten Dritter muss man dann schon mal auf stur schalten und die Lösch-Keule bei Google schwingen. In diesem Zusammenhang lohnen sich im Übrigen die von Datenschützern als "pöhse" bezeichneten Logprotokolle, wenn man - mit einiger Puzzlearbeit - einen Zusammenhang zwischen einem Bildabruf auf der eigenen Seite und einer zeitlich späteren Veröffentlichung dieses Bildes auf einer anderen Seite nachweisen kann.

Hallo Tom,

nachdem es mich auch "erwischt" hat mit einer Menge "ungültiger" Links, sind wir mit Hilfe unter anderem von kayboard inzwischen in der Eingrenzung so weit, dass es wohl noch Feintuningbedarf beim Header-Request gibt. Vorübergehend sollte es als Lösung funktionieren, die vollständige Adresse inklusive der jeweiligen index.html / index.php anzugeben.

Hintergrund: Insbesondere in Zusammenhang mit der Umstellung vieler Seiten auf https werden durch die Webseitenbetreiber über die .htaccess mehrere Umleitungsregeln erstellt, die von einem Aufruf ohne https auf die Seite mit https umleiten. Weitere Umleitungen gibt es für die Frage mit oder ohne vorangestelltem www und letztlich auch noch den Ausschluss von duplicate Content über den Aufruf mit oder ohne index.html / php. Dadurch kann es vorkommen, dass bei Aufruf des Links Umleitungen mehrfach wiederholt werden, was durch den Link-Prüfer momentan zu einer entsprechenden Fehlermeldung führt. Wie aus der Antwort von Uwe Keim schon zu entnehmen ist, ist das Problem bereit erkannt und in Arbeit. Bis dahin die Fehlermeldung entweder ignorieren oder die Links bis hin zu tatsächlichen .html-Datei ergänzen.

Morgen Yannick,

das klärt dann zumindest etwas auf, wie es zu den Angaben bei dnslytics kommt, wenn man mal die Bahnfotografie rückwärts verfolgt. Ich habe auf der etwas versteckten FAQ-Seite von MyLoc zumindest eine Anleitung zum Server-Reboot gefunden (wäre die Variante, wenn Du dort einen kompletten Server hast). Ansonsten geben die FAQ wenig her in Sachen PHP-Einstellungen.

scheint dort etwas komplizierter zu sein hinsichtlich der Zugriffsmöglichkeiten. Nach Dnslytisc https://dnslytics.com/domain/bahnfotografie-jwh.de ist wohl my Loc managed IT der Hoster, dies aber auf einem Server von 1&1. Yannik hat vermutlich nur einen Zugriff auf my Loc, nicht aber auf 1&1.

Hallo Yannick Kruse ,

zunächst zu den Website-Features. Habe gerade sehr an mir gezweifelt, ob ich nicht doch eine neue Brille brauche, da bei mir die Features nach wie vor nicht vorhanden sind. Bis ich vom Testprojekt wegen der Links wieder auf meine Vereinsseite gewechselt habe. Dort sind die Features vorhanden.

Deine Fehlermeldung sagt, dass keine PHP-Version vorhanden ist. Prüfe mal bitte im Control-Center Deines Hosters, was dort eingestellt ist.

Hallo Yannick,

da scheint was direkt bei deinem Server im Argen zu liegen. Der Aufruf http://bahnfotografie-jwh.de/assets/php/for…zp-php-info.php sollte eigentlich die Daten zu Deiner PHP-Version liefern, statt dessen wird die Datei heruntergeladen.

Ich wollte Dich gerade bitten, doch in Zeta den Test zu den Website-Features zu machen, sehe aber, dass diese Funktion in der 14.3 unter "Extras" ->"Optionen"->"Aktionen" gar nicht zur Verfügung steht. (Frage an Support : so beabsichtigt?)

Auf unserer Seite erfolgt die Anzeige der PHP-Version problemlos. Verwendest Du eine .htaccess? Wenn ja, poste mal den Inhalt als Quelltext </>

unter https://hosting.zeta-producer.com/5787125431/index.html liegt ein neues Testprojekt mit allen "fehlerhaften" Links unserer eigenen Homepage. Die Linkprüfung ergab die selben Fehler wie im Ursprungsprojekt. Alle Links sind aber direkt erreichbar.

wenn es denn beim alten Layout bleiben soll, ist der einfachste Weg, in den Footer einen Textartikel zu setzen mit einer Zeile und 6 Spalten. In die Spalten 1 - 4 kommen die Extralinks linksbündig, in Spalte 6 das Copyright rechtsbündig. Diesen Artikel auf "auf allen Seiten anzeigen" setzen und dann unter "Einstellungen" die "Extralinks" und das "Copyright" deaktivieren.

Hallo Stefan,

bei mir betrifft dies beispielsweise Links im Footer aller Seiten (wir danken für die Unterstützung 2018), so zu https://www.sciropposhop.ch/, einer Seite, die definitiv erreichbar ist. Ich bin jetzt bereits im Büro, kann aber heute Abend die Liste auch nochmal durchscrollen, ob auch der Link zu Zeta (https) und zu Walter (http) betroffen sind.

Hallo Nemessis,

habe das eben auch gerade mal durchgetestet.

Support : Bitte als Fehler aufnehmen. Dies Betrifft nach meinem Gefühl nur externe Links, die "falschen" Fehlermeldungen lauten wohl ausschließlich auf 403 (Du kommst hier nicht rein!). Auffällig ist, dass nach erster Prüfung (bei 242 Seiten gibt es natürlich auch jede Menge externe Links) nur Links betroffen sind, die entweder bereits mit https eingepflegt wurden oder aber inzwischen auf https umgestellt wurden. Das Verhalten ist neu in der 14.3.

Hallo iDesignish,

es geht vermutlich um die Seite http://www.sack-immobilien.de/. Dieses ist zwar noch im nicht weiter unterstützten Layout "Clean Style" gefertigt, in einem Nachbau konnte ich aber die 3 Extra-Links anlegen. Beim Nachbau habe ich zunächst das "Clean Style Responsive" gewählt, danach auf "Layout" ->"Layout wechseln"->"alte Layouts anzeigen" auf "Clean Style" umgestellt und danach die 3 Zusatzlinks gefüllt. Eventuell klappt es ja auch bei Dir über den Umweg "Layoutwechsel".

PS: Mache vorher ein Backup des Projektes, bei Layoutwechseln gehen individuelle Layouteinstellungen verloren.

Hallo André,

ja, dass ist richtig so. Dient wohl im Wesentlichen dem Verhindern von Fake-Bewertungen. Habe das Widget jetzt auch mal getestet, bin mir aber ziemlich sicher, dass wir es auf unserer Vereinsseite nicht einsetzen werden. Hinsichtlich weiterer Bewertungen durch den selben User könnten die Daten des Cookies "zpratinguser" interessant sein. Dieses läuft einen Monat nach Platzierung ab, also einfach mal die Testseite offen lassen und nach einem Monat versuchen, ob eine weitere Bewertung abgegeben werden kann.

Hallo zusammen,

es liegt tatsächlich am Provider, Onkel Google konnte aber weiterhelfen: https://hoster.wtf/11-eigene-smtp…rsand-geblockt/

Der Versand über SMTP klappt mit Port 25 und TLS

Nach der Änderung nicht vergessen, den DEBUG-Modus rauszunehmen.

Hallo Christine,

ich bin selbst bei 1&1 und nutze die V14. Habe Deine Fragestellung mal nachgebaut und komme zu dem selben Ergebnis. Weder über TLS (587) noch über SSL (465) kommt es zu einem Versand. Bei ausreichender Wartezeit kommt es zum von Dir beschriebenen Timeout.

Hallo Graf,

ich nutze dazu die Webseite https://dnslytics.com. Eine erste Abfrage nach der Domain liefert die IP-Adresse, die Suche nach der IP-Adresse liefert dann des Adressinhaber, also den Server, auf dem die Domain läuft. Gekommen bin ich auf die Seite, weil ich für unsere Vereinsverwaltung online (läuft unter einer eigenen Domain) den Zugriffsschutz über IP-Adressbereiche realisiere. Da es zur Vereinsverwaltung auch eine Handy-App gibt, funktioniert der Zugriffsschutz über htpasswd nicht. Mittels Verbot aller Adressbereiche und anschließender Genehmigung einzelner Adressbereiche lässt sich das aber ganz gut kompensieren.

Hallo Jürgen,

bei HostEurope (Postkartenparadies) wird ein Access-Log über alle Zugriffe geführt: https://www.hosteurope.de/faq/webhosting…ufbau-logfiles/

Bei FirstColo (Siegmann-Krimi) müsstest Du selber nachfragen, da deren Homepage keine FAQ bietet.

Grundsätzlich ist es so, dass die Hoster nach Gesetz über die Vorratsdatenspeicherung zum Führen eines entsprechenden Protokolls verpflichtet sind. Das Verwaltungsgericht Köln hat in dieser Sache aber geurteilt, dass die ansatzlose Vorratsdatenspeicherung gegen EU-Recht verstößt. Dies ist allerdings kein Grundsatzurteil, welches die Vorratsdatenspeicherung faktisch aushebelt, sondern nur die Rechtssprechung im konkreten Fall eines Hosters. Da das Urteil nur die anlasslose Speicherung betrifft und davon auszugehen ist, dass bei Hoster ein entsprechendes Log geführt wird (inklusive einer automatischen Anonymisierung nach einer bestimmten Zeit, bei 1&1 beispielsweise 7 Tage), sollten wir als Webseitenbetreiber die Speicherung mit einem Anlass versehen. Beispielsweise können wir berechtigtes Interesse an der Aufrechterhaltung der IT-Sicherheit und Integrität unserer Daten geltend machen, womit eine Speicherung der IP-Adresse unabhängig von der Einwilligung des Besuchers erfolgen kann. Einen entsprechenden Mustertext findest Du auf unserer Seite.

Hallo Siya,

mit der Umstellung auf den SFTP-Zugang hast Du auf physisch einen neuen Server. Daher der komplette Upload. Wir haben ja selbst rund 240 Seiten mit gut 2 GB Gesamtvolumen, da brauche ich rund 4 Stunden, alle Seiten zu erstellen und danach zu veröffentlichen.

Hallo Matthias,

dass geht bei Tabellen im Widget "Text" nur über CSS. Schaue Dir aber mal das Widget "tabellarische Daten" an. Dies ist der zeitgemäße Nachfolger der "Tabelle im Text". Hier kannst Du dann über "Stile" Text- und Hintergrundfarbe für Tabellenkopf sowie gerade und ungerade Zeilen separat festlegen. Im Wesentlichen geht es ja wohl nicht darum, dass der Text tatsächlich einen Rahmen hat, sondern die Zeilen optisch sauber voneinander getrennt sind.

Ich mache mal eine vorläufige Zusammenfassung, damit der Support hier morgen weitermachen kann:

1. Problem: Zum Download angebotene Word- und Excel-Dokumente werden bei Verwendung von Edge nicht als docx bzw. xlsx über Office geöffnet, sondern in einem neuen Browserfenster als html-Dateien mit entsprechend fehlerhafter Darstellung. Dieser Fehler tritt nur unter Edge auf. In Chrome können beide Dateien heruntergeladen werden.

2. Layout-Hinweis: Verwendet wird das Layout "Sport"

3. ursprüngliche Programmversion: 11 direktes Update auf 14.0.1, aktuell die 14.2.1

4. Hoster: Strato, PHP 7.1

5. Codierung: UTF-8 ohne BOM

Nachbau

Der Nachbau erfolgt zunächst in Zeta 13, da hier das Layout "Sport" noch verfügbar ist. Danach Kompimilierung in Zeta 14.2.1, beide Originaldateien über Widget "Button" hinzugefügt und unter https://hosting.zeta-producer.com/5768283762/index.html veröffentlicht. Die Dateien im Nachbau können in Edge geöffnet werden. Der Nachbau entspricht ansonsten den vorangestellten Angaben, lediglich als PHP-Version kommt auf dem Testserver eine 5.6 zur Anwendung. Die PHP-Version dürfte aber keine Auswirkungen auf den Download haben, da unter http://www.hanabi-pirna.de/test.php ebenfalls der Download der Dateien unter Edge mit PHP 7.1 möglich ist.

Hallo Bernd,

habe ich eben auch mal nachgebildet. Musste nur erstmal gucken, in welcher Zeta-Version das Layout "Sport" noch vorhanden ist. Die Fehler stammen anscheinend direkt vom Layout. "Sport" ist eines der älteren Layouts, die nicht mehr weiterentwickelt werden.

Hier mal die Testseite mit beiden Original-Dateien zum Download. Muss jetzt nur erstmal auf einen Rechner mit Edge wechseln. ... Test auf Edge ist erfolgreich.

Hallo Bernd,

vermutlich liegt es an Deinen Dateien und / oder an Deinem Server. Wir bieten unter https://www.hanabi-pirna.de/ki-ju/ausschreibung.html sowohl eine Excel-Tabelle als auch ein Word-Dokument an (Office 2010). Beide lassen sich mit Edge problemlos herunterladen und öffnen. Ich habe mal Deine nennung-01.docx in Chrome heruntergeladen, in Office 2010 geöffnet und gespeichert und danach unter https://www.hanabi-pirna.de/test.php sowohl meine Version als auch Dein Original in 2 Buttons zum Download eingebunden. Es lassen sich beide Dateien in Edge öffnen.

Ich tippe jetzt mal auf Probleme mit der Zeichencodierung. Gehe mal auf "Erweitert"->"Erweiterte Einstellungen"->"Kodierung". Dort sollte unten im Auswahlfeld "utf-8" drin stehen. Bei "BOM schreiben" darf kein Häkchen drin sein.

Falls es das nicht ist, überprüfe mal die unter https://validator.w3.org/nu/?showsource…Fbaustelle.html angezeigten Fehler.

Hallo Marcus,

ich kann da zumindest den Hintergrund liefern: Wenn wir Google-Webfonts auf unseren Seiten einbinden, passiert bei Aufruf der Seite durch den Besucher folgendes: Der Browser des Besuchers fragt beim Google-Server an, ob es zu den Schriften Änderungen gibt. Hierbei wird zumindest die IP-Adresse an den Google-Server übermittelt. Google erfährt also von unserem Besucher 2 Dinge: Die IP-Adresse sowie, dass er unsere Seite http://www.hanabi-pirna.de besucht hat. Danach besucht der Kunde die Seite http://www.sabrina-karlem.de, auf der ebenfalls ein Google-Webfonts eingebunden ist. Inzwischen weiß Google also schon, dass der Besucher aus dem Netz der Deutschen Telekom sich für Karate und Coaching interessiert. Wenn wir die Tour so weiterführen und nicht einen Besucher, sondern tausende Besucher und tausende Webseiten betrachten, kann Google ein regelrechtes Profil bis runter zum einzelnen Besucher erstellen.

Es ist also nicht ganz abwegig, bei Verwendung von Google-Webfonts auch an den Datenschutz zu denken. Dies insbesondere, weil nicht sichergestellt werden kann, dass der Browser eines europäischen Besuchers sich die Fonts-Informationen immer vom Google-Server Irland abholt. Er kann genauso gut auf einen Server außerhalb der EU zurückgreifen.

Das geht theoretisch weiter mit der Einbindung von Google-Maps. Aktuell haben wir ja gerade auch das Thema Einbindung von Videos über Youtube oder Vimeo im Forum gehabt. Das sind alles noch Fragen, wo man an die Grenzen der Machbarkeit kommt. So langsam zeigt sich auch, dass bei dieser "großartig geplanten" Datenschutzreform schlichtweg einige Sachen vergessen worden.

Nur mal als Beispiele:

- Wie kann ich Daten auf einer Visitenkarte, die mir bei einem Messebesuch übergeben wurde, datenschutzkonform verwerten? Ich brauche nach DSGVO eine Zustimmung des Betroffenen und muss diese dokumentieren können. Also schnell mal ein Blatt mit der Datenschutzerklärung vorgeholt, Visitenkarte oben links eingeklebt und dann vom Besucher am Messestand unterschreiben lassen!

- Muss eine Arzthelferin einen Anrufer, der erstmalig einen Termin in der Praxis vereinbaren will, über den Datenschutz belehren? Ja, denn sie wird den Namen in den Kalender des Arztes eintragen. Alternativ bekommt der Anrufer für einen Ersttermin nur eine Nummer zugeteilt, dann wird die Nummer im Kalender eingetragen und erst beim tatsächlichen Termin erfolgt die Datenschutzbelehrung. Man kann natürlich alternativ jeden Telefonanruf zunächst in eine Warteschleife schicken, bei der vom Band die Datenschutzerklärung vorgelesen wird. Am ende der Ansage kann der Anrufer dann mit Eingabe einer Ziffer bestätigen, dass er mit der Verarbeitung der Daten einverstanden ist "Drücken Sie Ziffer 1" und wird dann mit der Schwester verbunden, bei Eingabe der Ziffer 2 wird der Anruf beendet.

In diesem Sinne mit Peter Lustig:

Nachtrag: Habe inzwischen mal zu dem Thema gegoogelt und entdeckt, dass wohl zumindest bei youtube eine halbwegs datenschutzkonforme Lösung über eine Änderung des Einbettungscodes besteht. Ich schaue mir das noch mal im Detail an, checke auch noch vimeo und melde mich dann später noch mal.

PS: So langsam muss ich mir wirklich Gedanken um die Öffentlichkeitsarbeit für unseren Verein machen, weil die Datenschutzseiten inzwischen häufiger aufgerufen werden als die Seiten zum eigentlichen Karate-Training.

Hallo Lee,

Danke für Deinen Beitrag, da zeigt sich direkt doch noch eine Lücke, die ich beim DS-Konzept für unsere Vereinsseite übersehen habe.

Aus meiner Sicht ergeben sich zwei Lösungsansätze:

V1: Wenn es sich um (urheberrechtlich) eigenes Videomaterial handelt, dieses direkt über das Widget "Video-Player" anbieten. Dafür muss dann das Videomaterial als MP4 sowie als Webm und Ogg vorliegen, ist also etwas Aufwand außerhalb von Zeta notwendig.

Wenn es sich um Videomaterial handelt mit einer CC-Lizenz, muss man genau schauen, ob diese auf CC-0 (Rechteverzicht) lautet, Dann ist die Nutzung über Variante 1 möglich. Gleiches gilt für eine CC-BY-SA. Weitere Varianten der CC-BY (nachzulesen unter https://creativecommons.org/licenses/?lang=de) enthalten vielfältige Beschränkungen, so dass nur nach genauer Prüfung ebenfalls Variante 1 angewendet werden kann.

Für die Variante 2 kommt nur Videomaterial infrage, welches durch eine der anderen CC-BY-Lizenzarten geschützt ist oder ein individuelles Recht an der Verwertung des Materials eingeräumt wurde. Videos auf Youtube, die keine entsprechende CC-Lizenz haben oder an denen kein eigenes Recht besteht, dürfen aus Urheberrechtsgründen sowieso nicht auf der eigenen Homepage eingebunden werden.

V2: Die Videos werden auf einer Seite mit geschütztem Bereich über das Widget "Youtube" eingebunden. Diese Seite ist auf "nicht sichtbar im Navigationsmenü" gesetzt, damit über die normale Navigation nicht erreichbar. Sie kann aber weiterhin durch einen Link aufgerufen werden. Wir brauchen jetzt eine Vorschaltseite mit einem Formular, dass lediglich die Datenschutzbelehrung, das Passwort für den geschützten Bereich und ein Kontrollkästchen "Ich akzeptiere" (Pflichtfeld) enthält. Als "Erfolgs-URL" verwenden wir in diesem Fall nicht "Nachricht erfolgreich versendet", sondern die Video-Seite mit dem geschützten Bereich.

Dies sind die Varianten, die bereits mit Bordmitteln umsetzbar wären.

Je näher der 25. Mai rückt, des so aktiver werden sowohl die Anbieter diverser Internetdienste in den Umsetzungsvorbereitungen als auch die Datenschutzbehörden, die in den letzten Tagen quasi ein Grundsatzpapier nach dem anderen auf den Markt schmeißen, wo ich mich inzwischen frage, warum erst jetzt? Am 24. Mai wird wohl auch Youtube eine datenschutzkonforme Einbettung anbieten.

Hallo Caddle,

was für ein Vertrag läuft denn da? Könnte eigentlich nur entweder ein Uralt-Vertrag sein, bei dem PHP tatsächlich noch dazugebucht werden musste, oder ein Root-Server, der von Euch selbst administriert werden muss.

https://www.1und1.de/login, dann in der linken Übersicht auf "Hosting", dort dann in der rechten Spalte unterhalb "MySQL-Datenbank" auf "PHP-Einstellungen" und eine PHP-Version für die Seite wählen. Vorzugsweise solltest Du die 7.0 oder 7.1 benutzen. Nach ungefähr einer Minute steht die PHP-Version zur Verfügung und Du kannst in Zeta die Features erneut prüfen.

Das sieht ebenfalls richtig aus.

Die Fehlermeldung 403 spricht eigentlich für ein Verbot durch eine .htaccess, Auf dem Screenshot ist aber zu erkennen, dass sich außer 3 Ordnern nichts weiter in /php befindet.

Auf dem Server selbst läuft aber PHP? Ich kann das leider von hier aus nicht kontrollieren, da die entsprechende php-Datei in dem gesperrten Verzeichnis liegt. Gehe in Zeta auf "Extras"->"Optionen"->"Aktionen" und markieren dort den Eintrag in Zeile 3 "Website-Features prüfen" und dann auf "ausführen. Ergebnis hier melden. Wenn dort alles grün ist, bin ich mit meinem Latein am Ende und rate Dir zum Kauf eines Support-Tickets. Wenn eine Fehlermeldung ausgegeben wird, können wir damit weitersuchen.

gehe auf: "Layout" ->"Allgemein" ->"Seitenrahmen"->"Rand oben/unten"

Hallo Caddle,

die Dateiberechtigung erfährst Du in filezilla, indem Du auf den Ordner / die Datei gehst und dann die rechte Maustaste nutzt. Die Berechtigungen scheinen bei Dir aber erstmal mit 604 für Dateien und 755 für Ordner richtig zu sein. Du bist ja ebenfalls bei 1&1. Wenn ich auf meiner Testumgebung die Dateiberechtigungen ändere, bekomme ich die Fehlermeldung "Access denied", was also dem "Zugriff nicht erlaubt" entspricht.

Gehe mal in Filezilla auf das Verzeichnis /php. Wenn ich bei Dir das Verzeichnis /assets/ aufrufe, bekomme ich nämlich noch eine normale Anzeige, bei Aufruf von /assets/php/ kommt erstmalig die 403. Überprüfe dann die Dateiberechtigung wie oben.

Hallo Caddle,

verbinde dich mal über filezilla mit dem Webserver und überprüfe die Datei- und Ordnerberechtigungen im Ordner /assets/php/formmailer. Diese sollten auf 705 bzw. 755 (Ordner) sowie 604 (Dateien) stehen. Wenn dort andere Zahlen stehen, bitte hier posten. Hilfreich wäre außerdem ein Link zur Seite, damit eventuelle andere Fehler ausgeschlossen werden können.

Hallo Andrea,

da ist das charakteristische Verhalten bei Bella-Responsive. Hier mal das Original: https://content.zeta-producer.com/layouts/bella-responsive-bella/

Irgendwo müssen Menü, Sidebar, Header und Inhalt ja untergebracht werden. Du kannst aber hier im Forum nach "ausblenden ab" suchen. Das ist ein angepasstes CSS, mit dem die Kopfgrafik ab Unterschreitung einer bestimmten Bildschirmbreite ausgeblendet wird. Du kannst auch (nach einer Sicherung des bestehenden Projektes) verschiedene andere Layouts testen. "Locus" sieht beispielsweise auch auf dem Handy sehr gut aus.

Hier ist der ursprüngliche Thread: Neue Page hochgeladen, aber ohne Bilder...

Lade mal nur den Ordner /thumbnails über Filezilla in den entsprechenden Ordner auf dem Webspace hoch und achte dabei auf die entsprechenden Fehlermeldungen.

Hallo Norbert,

rufe mal http://hackgarten.de/buehne.html auf und lasse Dir dann den Quelltext anzeigen. Die Zeile 159 beginnt mit:

/script> </div> </div> </div> </div></div>

Da sind meiner Ansicht nach einige </div> zuviel. Das sollte jetzt zwar nichts mit dem fehlenden Upload zu tun haben. fällt aber trotzdem auf.

Der Fehler ist im Übrigen exakt der Fehler, den wir schon vor einem halben Jahr hatten, Thumbnails werden nicht angezeigt, weil sie auf dem Server nicht vorhanden sind. Die dazugehörigen Bilder-large werden problemlos auf den Server übertragen. Ich suche jetzt mal den alten Thread raus.