Archiv der Kategorie: Datenschutz

Der Tabelleneditor für die Negativliste: die Screenshots

Die Negativliste bearbeiten geht nur auf der Admin-Seite, das hab ich mal so festgelegt. Ich habe einen neuen Admin Menüpunkt “ Negativliste bearbeiten“ angelegt, wenn man den aufruft sieht die Startseite so aus:

Negativliste-bearbeiten

Die bereits vorhandenen Worte werden tabellarisch angezeigt, Man kann sie Löschen, dann öffnet sich das Unterformular und man muss nochmal auf den Button „Löschen“ klicken:

Wort-loeschen

Erst dann wird der Delete aktiv:

 Wort-loeschen-OK

 

…oder man kann einen neuen Eintrag anlegen.

Wort-eintragen

Ein kleines, aber rundes Feature, finden sie nicht auch? 🙂

Was mich allerdings beim Entwickeln ein bisschen ausgebremst hat: die Routinen für den Insert und Create und Delete haben mir ein paar Mal den Webserver abgeschossen bis sie fehlerfrei durchgelaufen sind, da half nur ein kompletter Neustart von Apache, MySQL und Xampp. Das darf natürlich in einer „richtigen“ WordPress-Umgebung nicht passieren, da muss man noch Fehlerbehandlungsroutinen einbauen. ich hab da jetzt aber keine Lust mehr dazu.

So, was fehlt noch? Ach ja, die Negativliste wartet noch auf ihren Einsatz beim Aufbau des Stichwortregisters. Das überleg ich mir morgen, wo man da am Geschicktesten einhakt.

Wenns so einfach wäre: die Tücken der lokalen WordPress-Installation

Ich gebs zu, ich hatte es mir einfacher vorgestellt, eine lokale Kopie dieses Blogs anzulegen. Dateien per SFTP runterladen… hat fast eine Stunde gedauert, war aber noch OK. Datenbankbackup einspielen… das ging recht flott, so nach 10 Minuten war MySQL damit fertig. wp_config anpassen (Datenbank Name, User Pwd etc.). Pfade in der wp_options anpassen. Dann liefs, aber mein Plugin lief nicht. Doch es lief so prinzipiell schon, die Erstellung der CSV-Datei aus den Beitragstiteln lief ohne Fehler durch. Aber später bei der Anzeige der Linkliste gabs Probleme. Die guid aus der wp_posts stand natürlich überall noch mit dem Serverpfad drin, da machte ein Klick die Life-Installation auf und zeigte brav den passenden Eintrag an. Menno, ich will aber die lokalen Beiträge haben…

In diesem gewohnt informativen Beitrag bei elmastudio wird vorgeschlagen, die Pfade in der Datenbank Backup Datei mit Hilfe von Notepad++ Suchen&Ersetzen anzupasssen und die Tabellen erst dann zu importieren. War ich wieder zu schnell.. also, Tabellen nochmal droppen und neuer Versuch. Ich melde mich dann wieder.

Also, nach mehreren vergeblichen Versuchen eine Webseite manuell umzuziehen ist es mir jetzt zu dumm geworden, und ich hab mich an das Plugin Duplicator erinnert, das besonders für kleinere Webseiten 1a geeignet ist. Hier bei Weptimizer findet man eine ausführliche Anleitung. Ich hab jetzt meinen Praxis Dr. Inselfisch Blog lokal umgezogen und geh mal mein Plugin testen.

Nachtrag: der Duplicator ist schon Klasse, er hat mir diesen Blog hier klaglos auf meinen lokalen Webserver umgezogen, auch wenn das Einspielen von 94 MB gezipptem Archiv schon ein Stück gedauert hat. Tolles Plugin, wirklich!

Danke, Gutenberg! Wenn Shortcodes nicht funzen…

… nehme man den Classic Editor. Nee, ohne Schmarrn, dem ist so. Ich hab gestern gedacht ich werde noch wahnsinnig, meine Shortcodes tun nicht das was sie sollen, ich krieg ständig diese bescheuerten JSON-Fehler. Permalinks neu erstellt, an- und abgemeldet, Webserver neu gestartet, half alles nix. Bis ich dann beim googlen auf den Hinweis gestossen bin, dass man auf den Classic Editor zurückswitchen soll, wenn diese Fehler auftreten.

Gesagt, getan. Und was soll ich sagen? Jetzt funken meine Shortcodes wieder. Das darf doch wohl nicht wahr sein! Ist natürlich verdammt ärgerlich. Und ich weiss nicht, ob ich bei meinen Life-Blogs wirklich auf den Classic Editor umstellen möchte, das muss ich mir noch schwer überlegen. Ist schon ein dicker Hund.

Intermezzo: warum ich so eine schlechte Programmiererin bin

Ich programmiere schon seit über 40 Jahren, und das meistens hauptberuflich. Ich habe in meinem Leben schon -zig Projekte kommen, gehen und sterben sehen und schon die tollsten Abenteuer erlebt. Aber eins hab ich noch nie gemocht: Fehlerbehandlungsroutinen (grusel)

Natürlich macht es Sinn, nach dem Versuch sich mit einer externen Datenbank zu verbinden abzuchecken, ob die Verbindung OK ist. Es macht Sinn zu überprüfen, ob eine weggeschriebene Datei existiert und den erhofften Inhalt hat. Es macht Sinn bei Lösch- und Aktualisierungsoperationen einen doppelten Boden einzubauen (..wollen Sie wirklich? Ja/Nein)

D’accord? Tscha, aber ich machs nicht. Seit ich im Ruhestand bin und eigentlich nur noch zum Vergnügen programmiere, erst recht nicht. Schließlich kann ich meistens mit auftretenden Fehlermeldungen etwas anfangen und korrigiere dann meinen Sourcecode entsprechend. Das kann ich mir deshalb erlauben, weil meine Projekte meistens Standalone-Routinen sind, zum Beispiel WordPress-Plugins oder VBA-Module. Mein Code ist selten länger als zwei, drei DIN A 4 Seiten und somit noch recht überschaubar, das geht schon. Guter Programmierstil ist es nicht, schon gar nicht wenn man in grösseren Projekten arbeitet – tu ich aber nicht (mehr).

Ich werde aber den Teufel tun und meine schlechten Programme in echt einsetzen, etwa auf meinen Live-Blogs (Inselfisch.Kochbuch, dieser Blog zum schwarzen Pinguin). Nee, die laufen auf meinem lokalen Xampp-Webserver auf den Test-Installationen oder in einer Access-Datenbank oder einer Exceltabelle, und ich lerne viel dabei. Und sei es, daß ein Programm so instabil läuft, daß es für den Livebetrieb gänzlich ungeeignet ist. That’s life. Mir macht Programmieren trotzdem Spaß! 🙂

Und wer bei mir was abkupfern möchte, kann das gerne tun, muss aber dann seine eigenen Fehlerbehandlungsroutinen einbauen. Ohne gehts im Echtbetrieb nun mal nicht.

Privatsphäre für personenbezogene Daten: das Plugin Secret Content

Adressdaten und Datenschutz

Jetzt haben wir also unser schönes Mitgliederverzeichnis mit allen Adressdaten und freuen uns darüber – aber mal langsam, so geht das „in echt“ natürlich nicht. Man kann nicht einfach Fotos und persönliche Daten von echten Personen ins Internet stellen und blind darauf vertrauen, daß schon nieman Schindluder damit treiben wird. Also muß ein Schutzmechanismus her, und genaugenommen müssen wir auch die Datenschutzerklärung (die auf dem Anmeldeformular) erweitern. Wie gehen wir das an?

Wir nutzen das WordPress-Login

Eine einfache Lösung ist es, unser Mitgliederverzeichnis nur für eingeloggte WordPress-Benutzer sichtbar zu machen. In unserem Fall ist das erstmal nur ich, der Admin, weitere Benutzer gibt es noch nicht (Werden wir aber noch brauchen, später, für die versprochene Suche nach Sportpartnern). Wie stellen wir es also an, daß unser Mitgliederverzeichnis nur für eingeloggte User sichtbar ist?

Das PluginSecret Content

Plugin-Seite: https://de.wordpress.org/plugins/secret-content/

Ich liebe Werkzeuge, die genau einen speziellen Zweck erfüllen und keinen Schnickschnack mitschleppen. Das Plugin Secret Content macht genau ein Ding: es ermöglicht einem, auf jeder Seite und auf jedem Beitrag anzugeben, daß sie nur für eingeloggte Benutzer sichtbar sein sollen. Nach Installation und Aktivierung des Plugins gibt es ein zusätzliches Fensterchen rechts oben im Editor, wo man anwählen kann, ob die Seite oder der Beitrag nur für eingeloggte Benutzer sichtbar sein soll.

secretcontent

secretcontent

Häkchen reinsetzen, speichern, fertig. Seite ist unsichtbar, wenn man nicht eingeloggt ist. Das wars! Das Plugin ist zwar seit über zwei Jahren nicht aktualisiert worden, aber es funktioniert einwandfrei, wieso sollte man daran was verbessern wollen?

Datenschutzerklärung anpassen nicht vergessen

Man muß das schon genau nehmen mit dem Schutz der personenbezogenen Daten, und deshalb müßten wir auch unsere Datenschutzerklärung auf dem Anmeldeformular anpassen, sobald wir echte Personendaten verwalten. Da gehört noch ein Passus hinein, daß Fotos und Adressdaten für andere Vereinsmitglieder sichtbar sind, wenn sie auf der Vereinsseite eingeloggt sind. Wie man das am Besten formuliert – ich würde im Echtfall einen Anwalt fragen, ganz ehrlich.

So, aber jetzt gehts weiter mit ein bißchen Spiel und Spaß mit PHP, wir machen uns an das Sportpartner-Suchformular, und dafür gibt es einen neuen Beitrag.

Plugins – auf Teufel komm raus?

Das Open Source Prinzip

Also, normal bin ich ja schon eine grosse Freundin von Open-Source-Software. Die Idee, Programmcode offenzulegen und für jeden Interessenten zugänglich zu machen, hat unbestreitbar viele Vorteile für den Otto-Normalanwender. Auf diesem Weg kommt man kostenlos an echt professionelle Software für fast alle Zwecke, vom alternativen Betriebssystem Linux über Open Office als echte Konkurrenz für Microsoft Office und noch vieles mehr bis eben hin zu unserem WordPress, dem Fex unter den Webdesignern für das kleine Budget. Durch die Offenlegung der Sourcen kann auch jeder Programmierer, der sich dazu berufen fühlt, eigene Erweiterungen schreiben und ebenfalls als Open Source zur Verfügung stellen. Es gibt heute 48,995 Plugins im wordpress.org Plugin Directory, und das sind nur die kostenlos erhältlichen. Von den gegen Honorar programmierten oder fertig käuflichen muß es noch viel mehr geben, jede kleine Softwareschmiede programmiert heutzutage Plugins für alle Zwecke für ihre Kunden.

Für jeden Zweck ein Helferlein

Ob sie jetzt einen Onlineshop oder ein Hobbyforum betreiben wollen oder nur ein paar  Kontaktformulare erstellen, ob sie einen Spamschutz brauchen oder ein komplettes SEO-Paket, ob es um Designanpassungen geht oder um Multimediaspielereien, es gibt für Tausend unterschiedliche Zwecke Plugins. Die Installation ist einfach, jeder Hobby-Wordpress-Admin hat schon -zig Plugins installiert, da sind ganz schnell mal so zwanzig, dreißig Installationen zusammen, und man hat eigentlich noch gar nicht viel gemacht.

Ein schwarzes Schaf dabei?

Ja, bis es dann passiert: ein Plugin zuviel installiert, und WordPress ist plötzlich beleidigt. Das muß nicht gleich der berüchtigte White Screen of Death sein, da können auch ganz andere Fehlfunktionen auftreten, die man vielleicht nicht gleich bemerkt. Da funktioniert plötzlich der Customizer nicht mehr, oder es verhaut das Seitenlayout, oder was auch immer da alles schiefgehen kann. Da wird dann immer wohlmeinend geraten, erst einmal alle Plugins zu deaktivieren und dann eins nach dem anderen wieder zu aktivieren, damit man herausfindet welches Helferlein denn nun den Ärger verursacht hat. Na prima. Und wenn man an sein WordPress gar nicht mehr rankommt? Kann man ihm immer noch das ganze Plugin-Verzeichnis unter dem Hintern wegziehen und schauen obs dann wieder normal läuft. Auch ’ne Lösung.

Denn sie wissen nicht, wer was tut

Jedem altgedienten Softwareentwickler da draussen sträuben sich hier natürlich alle Haare, das hat ja mit Datensicherheit überhaupt nichts mehr zu tun, aber bitte bürsten sie sich wieder flach, meine lieben Anwendungsprogrammierer und gelernten Informatiker, es kommt noch besser. WordPress lädt den Endanwender ja auch noch ein, den Plugin-Code zu verändern, man muß nur Im Plugin-Verzeichnis auf das Knöpferl „Bearbeiten“ klicken und landet mittenmang im Source-Editor und kann hier nach belieben Code verändern, löschen, herumkopieren und was weiß ich noch. Da muß noch nicht mal Absicht dahinterstecken, wie schnell hat man sich mal mit der Maus verklickt – und wenn man dann (vielleicht sogar nur aus Unwissenheit) die Änderungen speichert, ist das Malheur passiert.

Der Pferdefuß bei Open Source

Ja, echt wahr, sie können jetzt lang den Kopf schütteln, meine Damen und Herren gelernten ITler, aber so ist es nunmal. Jeder Endanwender kann nach Belieben den Sourcecode von Plugins bearbeiten, nix mit kompiliert, nix mit Kapselung, und schon gar nix mit Schutz von Gewährleistungsvoraussetzungen. Gewährleistung gibts nämlich bei Open Source nicht, weil die Grundlage dafür fehlt, nämlich der Schutz des Programmcodes vor unbefugten Änderungen.  Das haben sie und ich noch als strengste Auflage bei allen ernsthaften Programmierprojekten gelernt, aber vor lauter Open Source-Begeisterung ist dieser so wichtige Aspekt der Datensicherheit komplett ins Hintertreffen geraten. Da kann jetzt jeder selber seine Schlüsse ziehen, ob eine derart leicht zerhackbare Software für den professionellen Einsatz wirklich geeignet ist, oder nicht. Das mal so als Gedanke zum Feierabend.

 

Wer schreibt schon Kommentare? Die Spam-Bots!

Das mit den Kommentaren in WordPress ist so eine Sache. Da haben sich die WordPress-Entwickler echt Mühe gegeben und so richtig rangeklotzt, das sieht man an den fein einstellbaren Optionen unter Einstellungen/Kommentare. Ja und wozu? Jetzt will sie keiner!

Meine E-Mail soll ich angeben? Nein Danke!

Erstens schreibt kein Schwein einen Kommentar, wenn er seine E-Mail-Adresse hinterlassen soll. Das kann man zwar ausschalten, aber es ist per Default aktiviert, und schreckt erfahrungsgemäß ganz viele Besucher ab. Niemand möchte sich ungefragte Werbemails und Newsletter einfangen, und eine E-Mail-Adresse ist schließlich eine sehr persönliche Information, die man nicht so ohne weiteres auf einer fremden Seite eingibt. Ausserdem gibt es wohl eine sehr hohe Hemmschwelle, auf fremden Seiten überhaupt Spuren zu hinterlassen. Die überwiegende Mehrzahl der Besucher bleibt lieber in der passiven Betrachter-Rolle und kommentiert auch dann nicht, wenn die E-Mail-Addi nicht abgefragt wird. Anders sieht das in den unzähligen gutbesuchten Hobby- und Freizeitforen aus, da ist die Hemmschwelle derartig niedrig, daß die Leute in den Forenbeiträgen über alles, aber wirklich alles plaudern. Scheinbar ohne sich dessen bewußt zu sein, daß JEDER ihre Beiträge lesen kann. Schauen sie mal bei chefkoch.de in die Plauderecke, dann wissen sie was ich meine…
Aber das ist jetzt ein bißchen sehr Off Topic, zurück zu unserer durchschnittlichen WordPress-Webseite.

Kommentare zu geschäftlichen Seiten – macht das überhaupt Sinn?

WordPress ist ja das ideale Frontend für überschaubare Webauftritte von kleinen Unternehmen und Selbständigen, für den Metzger und die Gaststätte um die Ecke, für das Lebensmittelgeschäft, die Autowerkstatt, für Ärzte, Anwälte, Steuerberater – was diese Kundschaft benötigt, ist einfach eine Visitenkarte im Internet, in der sich die Firma darstellt, und in der die relevanten Firmeninformationen  (Geschäftsfeld, Angebote, Spezialitäten, Öffnungszeiten, Anfahrtskizze etc pp.) zu finden sind. Meistens  ist noch ein einfaches Kontaktformular gefragt, und mehr nicht. Das geht sogar noch weiter: die Blog-Funktionalität von WordPress wird größtenteils kaum genutzt, ganz selten gibt es mal die Anforderung nach einer Seite mit aktuellen Informationen wie z.B. die Wochenkarte eines Restaurants oder das monatliche Mandantenrundschreiben eines Steuerberaters. In der Regel aber sind die WordPress-Seiten für kleinere Unternehmen statisch, erfordern keinerlei Interaktivität und möchten auch bittesehr keine Kommentare haben, die werden fast immer ganz deaktiviert, punktum.

Und wie ist das mit dem Spam?

Das hält sich dank Akismet, Antispam Bee und Konsorten in sehr überschaubaren Grenzen. Ein Spamschutz-Plugin ist ein Muß für jede WordPress-Webseite, die irgendeine Art von Kontaktformular anbietet. Aber die bekannten Spamwächter funktionieren absolut zuverlässig und sind völlig problemlos sowohl in der Installation als auch im laufenden Betrieb.

Und was ist mit Captcha als Schutz?

Mit Kanonen auf Spatzen geschossen. Ausserdem sind Captcha und reCaptcha und wie sie alle heissen unüberwindliche Hindernisse im Sinne der Accessibility/Barrierefreiheit. Einen sehr informativen Artikel hierzu finden sie hier bei bitv-lotse.de, und den empfehle ich jetzt als Abendlektüre.

 

SQL – die vergessene Kunst?

Die dolle Olle – Structured Query Language

Meine zweite große Liebe auf dem Computer, ich hab es schon erwähnt, waren relationale Datenbanken und SQL. Die geniale Structured Query Language wurde an den Universitäten sehr gepflegt, schließlich ist sie ja auch von Wissenschaftlern für Wissenschaftler erdacht worden. Der ursprüngliche Zweck von SQL war ja die digitale Auswertung von Massendaten. Soweit ich weiß waren die Verhaltensforscher die ersten, die mit Hilfe von strukturierten Datenbanken wissenschaftlich fundierte Forschungsergebnisse erzielten. Mehr über die Geschichte und die Grundlagen von SQL kann man hier bei Wiki nachlesen, das ist spannend und gilt alles auch heute noch.

Ach so, und was hat das mit WordPress zu tun? Gemach, gemach.  Ohne MySQL kein WordPress. Mehr dazu (viel mehr!) später.

SQL ist SQL geblieben

Ich jedenfalls habe SQL damals an der Uni sozusagen mit der Muttermilch aufgesogen und habe früh erkannt, welcher Power und welche Vielseitigkeit im relationalen Datenbankmodell steckt. So kam es, daß ich als studierte Biologin in der EDV gelandet bin – und dort echt Karriere gemacht habe. SQL hat sich bis heute kaum verändert. Wer die Grundlagen einmal begriffen hat, dem ist es egal ob er es nun mit Oracle, Access oder SQL Server, MySQL oder sonst einem Dialekt zu tun hat. Einen Select, einen Join oder eine Where-Klausel schreibt man heute noch genauso wie vor 40 Jahren, da ist nicht viel passiert – wozu auch. Die alten SQL-Konzepte sind so gut, da ist nie etwas Besseres nachgekommen.

Datennormalisierung – wer kennt das heute noch?

Was allerdings heute in Vergessenheit geraten scheint, ist die grundlegende Strukturierung der Daten. In SQL-Datenbanken landet heutzutage häufig unkontrolliertes Datenmus, es ist eben zu einfach, irrsinnige Mengen an Daten automatisiert abzuschöpfen. Als Programmierer sitzt man dann zu oft vor einer ungenießbaren Datensuppe, aus der man eine strukturelle Logik erst mühsam herausfieseln muß, ehe man zu vernünftigen Abfrageergebnissen kommt. Dabei könnt’s so einfach sein – wenn sich heute noch jemand die Mühe machen würde, die grundlegenden Tabellen zu Normalisieren und eine vernünftige Struktur hineinzubringen.

Gottseidank gibts Datensuppe – und (noch) keine gläsernen Bürger

Ich bin eigentlich ganz froh, daß die heutzutage erhobenen Datenmengen so schlecht strukturiert sind. Wenn da mal jemand vernünftig aufräumen würde, wären wir ganz schnell beim gläsernen Bürger. Überlegen sie nur mal, was herauskäme, wenn all ihre Bank- und Behördendaten, ihre Handy- und Internetprofile, ihre Krankenkassendaten und was weiß ich noch alles sauber durchstrukturiert und per SQL ganz easy abfragbar wären. Dann hätten wir sie, Huxley’s Schöne Neue Welt – und ich bin heilfroh, daß es nicht so ist.

Unfreiwilliger Schutz vor der totalen Überwachung

Die irrsinnigen Mengen an Datenschrott, die heutzutage über jeden von uns in irgendwelchen Computern gespeichert sind, sollen bitte so unübersichtlich und unauswertbar bleiben, wie sie sind, das ist unser bester Schutz vor der totalen Digitalisierung, die mit den heutigen technischen Mitteln theoretisch schon möglich wäre. Praktisch umsetzbar ist sie (noch) nicht, weil bei der Unzahl an unterschiedlichen Systemen und labyrinthischen gewachsenen Strukturen keiner mehr durchblickt, und das soll bitteschön so bleiben. Daten-Müllhalden als Schutz vor der totalen Überwachung?

Besser als nix, wenn sie mich fragen. Lieber ärgere ich mich noch lange Jahre z.B. mit Behörden oder Versicherungen rum, weil die anscheinend keine Daten speichern (oder sie nicht wiederfinden) und man bei jedem kleinen Antrag alles noch mal von vorn ausfüllen muß. Ist für mich als Bürger etwas unbequem, aber ehrlich: wenn die alle auf Knopfdruck meine sämtlichen Daten da hätten, würde mir mulmig. Da sei St.Murphy vor, er bewahre uns bitte das behördliche Datenchaos. Amen! 😉