Heute veröffentlichen wir eine neue Version des ePartool. Diese neue Version 4.12 beinhaltet nahezu ausschließlich Fehlerbehebungen, Aktualisierungen der Programmbibliotheken und der technischen Dokumentation. Sie legt zudem den Grundstein für deutliche Überarbeitungen im kommenden Jahr.
Was wurde verändert?
Besonders hinweisen möchten wir darauf, dass das ePartool künftig nicht mehr mit PHP-Versionen vor 7.3 getestet wird. Wir haben uns für diesen Schritt entschieden, da PHP 7.3 schon länger bei allen großen Providern verfügbar ist und einige technische Verbesserungen und Geschwindigkeitszuwächse mit sich bringt. Das ePartool kann derzeit (wahrscheinlich) weiterhin auf PHP 7.2 betrieben werden. Allerdings ist zu beachten, dass hier Fehlerbehebungen der PHP-Community nur noch in unregelmäßigen Abständen zu erwarten sind und in einem Jahr komplett eingestellt werden.
Der Installationsassistent hatte in der vergangenen Version den notwendigen ersten Medien-Ordner nicht eingerichtet, was man bisher manuell korrigieren musste. Diese Nacharbeit ist nun nicht mehr notwendig.
Die Passwort-E-Mail ist auf vielfachen Wunsch künftig länger gültig: 24 Stunden lang kann man sich damit ein neues Passwort vergeben.
Wenn die System-E-Mail falsch eingetragen war, reagierte das ePartool bisher mit einem „Error 500“.
Der ePartool-Downloader, der die Installation gerade bei langsamen DSL-Leitungen deutlich beschleunigt, da man direkt auf den Server herunterladen kann, ist ebenfalls aktualisiert worden. Er testet den Server und gibt Tipps, wenn Probleme gefunden werden. Alle neuen Installations- und Update-Dateien finden sich hier.
Wir haben uns dazu entschieden, dass wir sehr alte ePartool-Versionen nicht mehr direkt als Download zur Verfügung stellen. Die älteste Version auf unserem Server ist daher seit heute die 4.5.3 von Mitte 2017. Diese Version war die erste, die von vorherigen Versionen direkt geupdatet werden konnte.
Mitentwickeln
Das ePartool wird öffentlich einsehbar auf Github [github.com/DeutscherBundesjugendring/epartool] entwickelt. Wir haben weiter an einer guten technischen Dokumentation gearbeitet. Neben oben beschriebenen Verbesserungen fanden viele Aktualsierungen von externen Programmbibliotheken statt. Auch wurden die Ruby-Abhängigkeiten für die Jekyll-Dokumentation (Github Pages) ebenfalls aktualisiert. Für die Mitentwicklung ist künftig mindestens NodeJS 10 notwendig.
Wie geht die Weiterentwicklung 2020 weiter?
Nach einem relativ ruhigen Jahr wollen wir das ePartool 2020 wieder deutlich erneuern. Wir haben dazu neben unseren eigenen Ideen zahlreiche Rückmeldungen von Nutzenden gesammelt und freuen uns natürlich weiterhin über Feedback.
Unsere Pläne sehen folgende Schwerpunkte vor:
Die Nutzeroberfläche soll entschlackt werden, dass sie nicht mehr so überfachtet ist. Gerade für nur gelegentlich stattfindende Beteiligungsrunden ist das ePartool bisher zu komplex.
Über Mittel von „Progressive Web Apps“ soll das ePartool so gestaltet werden, dass es sich für Nutzer*innen wie eine Smartphone-App nutzen lässt.
Für einzelne Beteiligungsrunden soll es eine Startseite geben, bzw. die Möglichkeit die jetzige Startseite besser auf genau eine laufende Maßnahme anzupassen.
Die Registrierung soll nicht länger nur per E-Mail möglich sein, da Jugendliche heutzutage eher über Messenger erreicht werden können: Hier sind aber noch einige Fragen nach Schnittstellen und Datenschutz zu klären.
Beteiligungsrunden sollen auch mit Audio und Bilder-Uploads ermöglicht werden. Videos sollen möglicherweise auch direkt hochgeladen werden können, um nicht wie bisher auf Fremdplattformen angewiesen zu sein.
Neue ePartool-Versionen sollen direkt über einen komfortablen Updater einzuspielen sein.
Am Wochenende wurde ein kleines Update von Antragsgrün veröffentlicht. Es beinhaltet vor allem Fehlerbehebungen sowie kleine Verbesserungen für den Multi-Site-Betrieb. Wir empfehlen euch das Update über den Online-Updater im Backend von Antragsgrün einzuspielen. Der Aktualisierungsvorgang erfordert nur wenige Mausklicks und ist in weniger als einer Minute abgeschlossen.
Welche Probleme wurden behoben
Logos, deren Dateinamen bestimmte Sonderzeichen beinhalteten, wurden beim PDF-Export nicht angezeigt.
Schlagwörter mit dem &-Zeichen wurden zuvor falsch kodiert. Wichtig zu wissen: Die Fehlerbehebung verändert die alten Schlagwörter nicht rückwirkend, sondern kann nur die korrekte Erstellung neuer Tags sicherstellen.
Wenn Nutzer*innen Kommentare entfernt hatten, trug Antragsgrün bisher verwirrende Einträge ins Aktivitäten-Log ein.
Wenn Nutzer*innen ohne Login PDF-Dokumente zu Bewerbungsverfahren hochgeladen hatten, zeigte Antragsgrün bisher das PDF auf der Bestätigungsseite nicht korrekt an.
Das Aussehen von Links in der Seitenleiste ist nun einheitlicher.
Beim Anlegen der Liste von administrativen E-Mail-Adressen für Benachrichtigungen kann als Trennzeichen nun sowohl Komma wie auch Semikolon verwendet werden.
Verbesserungen im Multi-Site-Betrieb
Wenn Antragsgrün im Multi-Site-Modus betrieben wird, also eine gemeinsame Antragsgrün-Installation über mehrere Domains angesprochen werden kann, sind Plugins nun einzeln pro Subdomain aktivierbar. Ebenso setzt Antragsgrün nun die E-Mail-Adresse des Admins automatisch als Reply-To für Systemmails, falls für die Subdomain nichts Anderes eingerichtet wurde.
Noch kein Antragsgrün in Benutzung?
Wer Antragsgrün erstmalig installieren möchte, erhält die Installationsdateien wie immer direkt im öffentlichen Github-Repository: https://github.com/CatoTH/antragsgruen/releases. Die Installations-Datei (z.B. als ZIP) muss entpackt und in ein Verzeichnis bei eurem Webhoster transferiert werden. Beim ersten Aufruf des Verzeichnisses über euren Browser startet der Einrichtungsassistent, der die Datenbank und die erste Veranstaltung anlegt.
Mittlerweile stehen viele hochwertige Open-Source-Anwendungen für eure Onlineauftritte oder Onlinezusammenarbeit zur Verfügung. Auch wenn sich Entwickler*innen große Mühe geben eine tolle Software zu schreiben, so schleichen sich doch immer wieder Fehler ein. Ebenso können sich im Zusammenspiel zwischen Anwendung und eigenem Server Probleme auftun, die einer Lösung bedürfen. Vor der Lösung steht jedoch die Fehlersuche: Oft lässt sich nicht per Augenschein erkennen, woran es hakt. Im Folgenden geben wir ein paar Tipps, wie ihr euch dem Problem nähert.
Die Log-Datei ist dein Freund!
Glücklicherweise werdet ihr bei der Fehlersuche von der Software
aktiv unterstützt. Die meisten Anwendungen und auch die Server
selbst legen verschiedene Protokoll-Dateien an. In diesen wird
aufgezeichnet, welche Aktionen stattgefunden haben bzw. bei welchen
Aktionen unvorhergesehene Ereignisse auftraten. Aus unserer Erfahrung
lohnt es sich bei Problemen im ersten Schritt die Log-Dateien der
betroffenen Anwendung anzusehen. Die meisten Fehler lassen sich
hierüber bereits eingrenzen.
Log-Dateien werden
fast immer als Dateien mit der Endung .log angelegt. Es handelt sich
dabei aber in der Regel um Textdateien, die sich mit jedem beliebigen
Editor öffnen lassen (Notepad, Wordpad, usw.).
In den Logs der
Anwendungen wird in der Regel protokolliert, wenn einzelne Funktionen
oder Programmbibliotheken eine Aufgabe nicht ausführen konnten. Das
könnte z.B. daran liegen, dass Zugriffsrechte nicht korrekt gesetzt
waren, benötigte Dateien nicht gefunden wurden, ein Datenbankserver
nicht oder nicht schnell genug geantwortet hat, oder Funktionen
schlichtweg Fehler hatten (Beispiel: Versuch durch 0 zu teilen).
Dennoch können sich die Inhalte der Log-Dateien bisweilen sehr
unterscheiden – die Entwickler*innen können sich dafür
entscheiden, nicht nur fatale Fehler zu vermerken, sondern auch
bereits Warnmeldungen oder auch erfolgreich durchgeführte
Aktivitäten. Letzteres kann zwar von Interesse für die
Entwickler*innen sein, allerdings im Dauerbetrieb auch mit
Datenschutzerfordernissen kollidieren. Daher lassen sich Anwendungen
häufig darauf konfigurieren, ob sie sich im Betriebsmodus für
„Entwicklung“ (development, debug modus) oder für „Produktion“
befinden.
Anhand von vier Anwendungen möchten wir euch beispielhaft aufzeigen, wo Log-Dateien zu finden sind:
Antragsgrün:
Die Software zur demokratischen Texterstellung führt eine Log-Datei
unter /runtime/logs/app.log. Die Einträge sind dabei sehr
ausführlich gehalten.
ePartool: Das
DBJR-Konsultationswerkzeug führt eine Log-Datei unter
/runtime/logs/application.log. Die neuesten Einträge finden sich
ganz unten.
Nextcloud:
Die populäre Open-Source-Plattform für Dateiaustausch und
Zusammenarbeit führt zwei unterschiedliche Log-Dateien. Während die
Datei /data/updater.log nur über Installationsvorgänge Buch führt,
ist die Datei /data/nextcloud.log für den täglichen Betrieb
gedacht. Nextcloud beinhaltet zudem eine Zugriffsmöglichkeit auf
diese Log-Datei über das Admin-Backend. Hier kann man auch
einstellen, welche Art von Fehlern oder Problemhinweisen
protokolliert werden sollen.
WordPress: In
der Standardinstallation führt das CMS keine Log-Datei. Durch zwei
Einträge in der Datei wp-config.php kann das Loggen aber aktiviert
werden:
Wenn man Log-Dateien
über das administrative Backend betrachten und auswerten möchte,
muss zudem ein Plugin installiert werden, z.B. der »Error Log
Monitor« [https://de.wordpress.org/plugins/error-log-monitor/]
Weitere Log-Dateien
Gelegentlich helfen
die Log-Dateien der Anwendungen aber nicht weiter. Das kann daran
liegen, dass die Anwendung auf Probleme stößt, die außerhalb ihrer
eigenen Analysemöglichkeit liegen. Im Extremfall wäre das bei einem
Hardware-Defekt der Fall: Ob alle Kabel richtig stecken oder ob der
Servercomputer selbst richtig rechnet, kann eine Anwendung kaum
erkennen. Auf Log-Dateien der Betriebssystem-Ebene hat man jedoch in
der Regel als Mieter*in eines Webhostings keinen Zugriff.
Professionelle Provider stellen durch Überwachungsprogramme sicher,
dass diese Art von Fehlern von ihnen selbst zeitnah entdeckt werden.
Zwischen dem
Betriebssystem und Anwendungen wie den vier oben genannten liegt
allerdings noch die installierte Web-Server-Software. Ein Web-Server
ist meist als Sammelbegriff mehrerer Programme zu verstehen und
beinhaltet neben dem eigentlichen Web-Server-Programmen wie Apache
oder Nginx auch die PHP-Programmiersprache oder eine Datenbank).
Diese alle führen ebenfalls Log-Dateien.
Welche Log-Datei
hilft wann:
Web-Server:
Hier werden der Zeitpunkt und die Herkunft der Zugriffe
(IP-Adressen), Größe der abgerufenen Dateien und Statusmeldungen zu
den einzelnen Verbindung geloggt. So lässt sich schnell
herausfinden, ob es zeitgleich übermäßig viele Zugriffe gab (und
daher der Server sehr langsam wurde) oder ob bestimmte Dateien nicht
gefunden wurden (die bekannte Statusmeldung 404). Probleme im
internen Programmablauf, die nicht die Zugriffe betreffen, werden
meistens in einer separaten Log-Datei protokolliert.
PHP: Programmierfehler sind häufig kleine Tippfehler, wie eine vergessene Klammer zum Abschluss einer Funktion oder ein Buchstabendreher. Wenn der PHP-Interpreter nicht versteht, was er zu tun hat, können diese Fehler entweder geloggt oder direkt angezeigt werden. Letzteres hilft zwar, Fehler schnell zu finden, verrät aber Externen auch viel über mögliche Angriffspunkte. Bei PHP-Skripten kann man auch ohne viel Programmiererfahrung das Anzeigen von Fehlern aktivieren, indem man in die ersten Zeilen (nach dem Startkennzeichen <?php) folgende Befehle ergänzt:
Voraussetzung dafür, dass nun konkrete Fehlermeldungen angezeigt werden, ist, dass der Server grundsätzlich dazu konfiguriert ist. Bei den meisten Providern lässt sich das im Administrationsmenü aktivieren und wieder deaktivieren. Bei direktem Server-Zugang und Schreibrechten auf die php.ini-Einstellungsdatei lässt sich dies durch display_errors = on aktivieren.
Datenbank: Da
es verschiedene weit verbreitete Datenbanken gibt, fällt die
Erkenntnismöglichkeit hier sehr unterschiedlich aus. General lässt
sich über die Log-Datei herausfinden, ob der Service korrekt
gestartet wurde, ob es gescheiterte Zugriffsversuche gab (z.B. wenn
die Zugangspasswörter in der zugreifenden Anwendung falsch
abgespeichert waren). Möglicherweise kann man über die
Statusmitteilungen auch herausfinden, ob Datenbank-Anfragen
ineffizient gestellt wurden und daher sehr lange zur Beantwortung
brauchten oder gar komplett scheiterten. Dies könnte z.B. der Fall
sein, wenn Suchindizes nach größeren Datenveränderungen nicht neu
angelegt wurden oder durch zu viele parallel Schreibvorgänge
versucht wurden. Auch der Ursprung von fehlerhafte Zeichenausgabe
(Umlaute oder falsche Symbole) könnte hier liegen: Die Kette der
Zeichenkodierung muss von der Datenbankablage über die Verbindung
und Verarbeitung bei der Anwendung bis hin zum Browser bei den
Nutzer*innen durchgehend richtig sein.
Der Einfluss von Fehler-Logs auf die Rechenzeit
Das Erstellen von
Log-Dateien benötigt immer etwas Rechenzeit. Diese fällt umso
größer aus, wenn man sich auf einem höheren Software-Level
befindet (System → Server-Software → Anwendung). Daher lohnt es
sich bei viel frequentierten Internet-Angeboten, im stabilen Betrieb
das Logging durch die Anwendungen soweit wie möglich zu reduzieren.
Wenn man neue Website-Anwendungen oder Online-Portale einrichtet, findet sich in der Installationsanleitung häufig auch der Hinweis, dass ein »Cronjob« einzurichten sei. Aber worum handelt es sich dabei eigentlich?
Cronjobs beinhalten Aufgaben, die regelmäßig oder zu bestimmten Zeitpunkten stattfinden sollen. Ein Beispiel wäre ein automatischer Versand von E-Mails zur Erinnerung an Fristen oder tägliche Zusammenfassungen eines Forums. Diese Mails werden in der Regel nicht jedes Mal von einem Menschen zusammengestellt, sondern von der Server-Software.
Gebraucht werden diese wiederkehrenden Aufgaben vor allem auf Systemen, die rund um die Uhr laufen: Backups werden automatisiert angelegt oder bestimmte Systembereinigungen können so regelmäßig zu weniger frequentierten Zeiten (meist nachts) ablaufen. Das Entkoppeln von Momenten hoher Systemlast und Hintergrundaufgaben, die auch zu anderen Zeitpunkten stattfinden können, stellt den neben termingebundenen Aufgaben einen weiteren großen Vorteil von Cronjobs dar – ein typisches Beispiel wäre die Aktualisierung eines Inhaltsindexes für die Suchfunktion: Diese muss nicht exakt in dem Moment geschehen, wenn ein neuer Artikel in die Datenbank eingetragen wird, sondern darf meist auch einige Minuten später erst erfolgen.
Auf Arbeitsplatzrechnern oder Notebooks hingegen sind Cronjobs seltener anzutreffen. Oft werden wiederkehrende Aufgaben wie die Suche nach neuen Antivirus-Signaturen einfach jedes Mal bei Systemstart durchgeführt.
Für einen Cronjob benötigt man die Aufgaben, die erledigt werden sollen, niedergeschrieben in einem Programmskript. Skripte in einer Programmiersprache wie PHP, die gerade bei Website-Anwendungen sehr beliebt ist, kann aber von einem Server nicht direkt verstanden werden, sondern muss von einem »Interpreter« übersetzt werden. Welcher das ist, muss beim Einrichten eines Cronjobs ebenfalls angegeben werden. Und schließlich sind die Zeitangaben für das Ausführen wichtig – hier gibt es eine Fülle von Möglichkeiten (siehe Grafik).
Cronjobs werden tabellarisch in einer Crontab-Datei abgespeichert. Bei Webhosting-Providern ist häufig eine grafische Benutzeroberfläche vorhanden, um die Jobs einzutragen und zu verwalten. Leider sind dabei oft Begrenzungen vorgegeben, z.B. dass mindestens zwei Stunden zwischen der Ausführung eines Cronjobs liegen muss. Für Web-Anwendungen, die häufiger solche Hintergrundaufgaben benötigen, kann man den Cronjob dann ggf. mehrfach anlegen: Während der erste z.B. zu allen ungeraden Stunden ausgeführt würde, wäre Cronjob 2 für alle geraden Stunden zuständig.
Gelegentlich sind Cronjobs mit Zugriffstokens abgesichert, d.h. nur wenn man eine Art Passwort mit übermittelt, wird der Cronjob ausgeführt. Dieses Verfahren setzen wir u.a. im ePartool ein, um sicherzustellen, dass ein Cronjob nicht missbräuchlich zum Spam-Mail-Versenden fehlgeleitet werden kann.
Nextcloud ist ein datenschutzbewusster Gegenentwurf zu den großen Cloudanbietern und bietet vielfältige Möglichkeiten für Dateiaustausch und Onlinezusammenarbeit. Diese selbst betriebene Cloud ist dabei ausgesprochen genügsam: Sogar auf einfachen, gemieteten Webhosting-Paketen kann Nextcloud eingerichtet und mit Freund*innen und Kolleg*innen genutzt werden – sogar noch parallel zu einer bestehenden Website. Zusätzlich Kosten für den Betrieb können so vermieden werden.
Wer so eine kleine Nextcloud-Instanz betreibt, kann damit ohne Weiteres mit 20-50 gleichzeitig aktiven Nutzer*innen zurechtkommen: Die meisten Funktionen und Erweiterungs-Apps funktionieren ganz wunderbar. Einschränkungen treten im Betrieb am ehesten in Erscheinung, wenn mehrere Personen zeitgleich mit derselben Datei arbeiten oder auf aufwändige Funktionen zugreifen. In solchen Fällen geht nichts kaputt, aber es kann passieren, dass Nextcloud Dateien zu konservativ vor einem Löschversuch schützt.
Während die Nutzung von Nextcloud auf einfachen Webhosting-Paketen gut möglich ist, sind hier vor allem die administrativen Funktionen eingeschränkt: Auf einem „richtigen“ Server kann das Nextcloud-eigene Konfigurationswerkzeug OCC benutzt werden; kostengünstige Shared-Hostings erlauben jedoch meist keinen SSH- und damit keinen Befehlszeilen-Zugriff. Das erschwert Wartungsarbeiten, insbesondere wenn nach einer Versionsaktualisierung bestimmte Datenbank-Aktionen oder Neuindizierungen empfohlen werden oder zentrale Aufgaben für mehrere Nutzer*innen anstehen. Diese Aufgaben per Hand direkt in der Datenbank oder in diversen Installationsverzeichnissen zu erledigen ist unkomfortabel, technisch anspruchsvoll und fehleranfällig. Bisher gab es dazu aber keinen anderen Weg.
Das Wehklagen der Admins wurde von den Nextcloud-Entwickler*innen jedoch ernst genommen: Seit wenigen Tagen existiert ein Plug-in (in Nextcloud-Sprache: „App“), das die Befehlszeileneingabe direkt im Backend nachrüstet: Ein Admin kann sich also ins Backend einloggen und die notwendigen OCC-Befehle hierüber eingeben. Auch ist diese „OCC Web“ genannte Erweiterung recht hilfsbereit und zeigt nach Drücken der ENTER-Taste alle verfügbaren Befehle und deren Bedeutung an. Auch Wartungsfunktionen für andere installierte NC-Apps stehen bereit.
Als Admin sollte man sich bei allen Vorteilen von »OCC Web« dennoch überlegen, ob man diese Erweiterung nur anlassbezogen oder dauerhaft einrichtet. Möglicherweise tun sich über die administrativen Funktionen Angriffsvektoren für Bots oder Schädlinge auf, die die Nextcloud-Instanz übers Web erreichen können. Generelle gilt, dass jede installierte App stellt ein mögliches Einfalltor darstellt, vor allem wenn sie sich noch recht jung in Entwicklung befindet. Daher könnte es sinnvoll sein, OCC Web nur im konkreten Bedarfsfall zu installieren und danach wieder herauszunehmen – in Nextcloud eine Sache von wenigen Sekunden.
Und wofür steht nun eigentlich das Kürzel »OCC«? „OCC“ wurde bereits eingeführt, als sich das Nextcloud-Projekt noch nicht von OwnCloud abgetrennt hatte. Daher bedeutet die Abkürzung OCC vermutlich „OwnCloud Configuration“ und wurde in Nextcloud so beibehalten.
Eine Open-Source-Software wie Antragsgrün lässt jederzeit Veränderungen an der Programmierung zu. Gelegentlich sind aber Funktionen auch bereits eingebaut, selbst wenn sie für die Außenwelt nicht gut dokumentiert sind. Eine solche Option möchten wir euch heute vorstellen.
Nach der Einrichtung von Antragsgrün findet sich auf der Startseite der neuen Installation eine kleine „Werbebox“, die neuen Interessierten den Weg zum eigenen Antragsgrün erleichtern soll. Der Hinweistext ist allerdings noch für die ursprüngliche Zielgruppe von Partei-Aktiven formuliert und ist daher für andere Zielgruppen, gerade in der Jugendarbeit, eher verwirrend.
Die Box lässt sich leider nicht über die Einstellungen im Backend unsichtbar schalten. Über einen kleinen Eintrag in der dazugehörigen (MySQL-)Datenbank funktioniert das dennoch. Und das geht so: Ruft die Datenbankadministration bei eurem Server/Provider auf. Oftmals ist das z.B. das Werkzeug PHPMyAdmin. Ihr müsst in der Antragsgrün-Datenbank die Tabelle »site« suchen und dort im Feld „settings“ den Wert von „showAntragsgruenAd“ von „true“ auf „false“ setzen. Im Screenshot anbei seht ihr, wie das Datenbankfeld korrekt formuliert ist.
Leider hat sich in den letzten Versionen des ePartools ein Fehler eingeschlichen, der nur bei Neuinstallationen auftreten kann. Der Fehler wirkt auf den ersten Blick fatal, doch die Abhilfe ist sehr einfach. Updates von bestehenden Installationen sind von dem Problem generell nicht betroffen.
Worum geht’s: Das ePartool richtet selbsttätig für jede Beteiligungsrunde einen eigenen Medienordner ein, um darin Grafiken und Dokumente abzulegen. Diese Ordner werden aufsteigend durchnummeriert ab der Zahl „1“. Unglücklicherweise scheint der Installer das Anlegen für die allererste Beteiligungsrunde in manchen Server-Settings zu „vergessen“. Das Problem macht sich erst dann durch eine Fehlerseite bemerkbar, wenn ihr euer erstes Bild oder Dokument hochladen wollt – das Bearbeiten von Artikeln und Beiträgen funktioniert jedoch.
Der Fehler ist jedoch schnell behoben. Am besten loggt ihr euch auf dem Server per SFTP ein und erstellt folgenden Ordner mit dem Namen „1“:
epartool-ordner/www/media/consultations/1/
Problem gelöst! Wir werden den Fehler in der nächsten Version des ePartool-Installers beheben. Vor der Winterpause wird jedoch aus Kapazitätsgründen keine neue Version mehr erscheinen.
Heute haben wir das ePartool in Version 4.11.1 veröffentlicht. Diese Version beinhaltet lediglich Detailverbesserungen, kleinere sprachliche Überarbeitungen sowie zusätzliche Hilfe für Admins, wenn sie bei der Installation die Einrichtung der .htaccess-Datei übersehen haben.
Wenn bei der Installation vergessen wurde die .htaccess-Datei richtig einzurichten, dann weist das ePartool künftig darauf hin.
Für Installationen, die bereits das ePartool in Version 4.11.0 einsetzen, ist ein Update nicht erforderlich.
Darüber hinaus haben wir ein kleines Update des komfortablen Direkt-Downloaders für die ePartool-Installation veröffentlicht: Die wichtigste Neuerung in v1.3 ist dabei, dass das ePartool sich nun nicht mehr auf veraltetem PHP 5.6 installieren lässt. Warum? Ab Ende Dezember werden für diese Uralt-Version keine Sicherheitsupdates mehr erscheinen. Wir empfehlen den Einsatz von PHP 7.1 oder 7.2.
Auch hier gilt: Wer den ePartool Web-Downloader 1.2 bereits erfolgreich verwendet, muss nicht unbedingt umsteigen.
Eine ausführliche Installations- und Update-Anleitung findet sich wie bisher unter Installation / Download.
Nach langer Entwicklungszeit und insgesamt neun Vorabversionen ist am Wochenende Antragsgrün in einer stabilen Version 4.0.1 freigegeben worden. Was den Versionssprung auf die 4er-Reihe ausmacht, stellen wir im Folgenden vor.
Für die Ungeduldigen: Antragsgrün 4 bietet einen komfortablen Web-Updater, ein neues Kommentarsystem, die Möglichkeit für redaktionelle Inhaltsseiten im Menü, eine automatische Exportfunktion für der eigenen Daten, das Hochladen von Bildern und Vorbereitungen für ein Plugin-System.
Antragsgrün aktuell halten: ab jetzt über einen komfortablen Web-Updater
Antragsgrün wird sehr aktiv weiter entwickelt. Während das eigentlich eine erfreuliche Sache ist, stehen damit Organisationen auch vor einem Problem: Wer aktualisiert unsere Installation? Bisher war dies nur mit technischer Unterstützung durch eure Serveradministration möglich. Dieser Prozess ist nun deutlich vereinfacht worden. Logins für eure Antragsgrün-Installation mit Admin-Rechten sehen nun automatisch eine Hinweisbox, die auf neue Versionen hinweist. Per Mausklick kann in den »Update-Modus« geschaltet werden, der die Aktualisierung dann automatisch vornimmt. Andere Nutzer*innen können während dieser wenigen Augenblick das System nicht benutzen und erhalten stattdessen einen Warnhinweis.
Auch wenn die Update-Funktion von Antragsgrün nun über ein paar Monate ausführlich getestet wurde, solltet ihr vor einem Update immer sicherstellen, dass Ihr eine Sicherungskopie der bisherigen Installation habt. Viele Webhosting-Provider bieten diesen Service automatisiert an, d.h. eine Sicherung läuft beispielsweise täglich nachts. Wenn etwas schiefgelaufen ist, könnt ihr eure Installation und die Daten mit Stand des Vortags wieder herstellen.
Kommentieren und informieren
Antragsgrün 4 bietet sowohl für Nutzer*innen/Teilnehmende wie auch für die Verantwortlichen eine Reihe von Verbesserungen und zusätzlichen Funktionen.
Das Kommentarsystem wurde überarbeitet: Man kann auf Kommentare wiederum antworten; die Darstellung ist zugleich kompakter als früher.
Automatische Benachrichtigungen können einfacher eingerichtet werden.
Administrative Texte (z.B. oben auf der Begrüßungsseite) können nun bequem Bilder einbetten.
Es ist möglich Unterseiten wie in einem CMS anzulegen (z.B. für Seiten mit Anfahrtsbeschreibung o.ä.)
Möglichkeit weitere Buttons in der Sidebar.
Man kann zentral Nachrichten hinterlegen, die nach einem Login für die Nutzer*innen erscheinen.
Jede einzelne Veranstaltung kann nun ihr eigenes Logo besitzen. Unsere Tests haben gezeigt, dass noch ein wenig Nacharbeit nötig ist, damit vorhandene Logos aus vorherigen Veranstaltungen bei Bedarf einfach wiederverwendet werden können. Diese Verbesserung ist in einem der kommenden Updates zu erwarten.
Administration und technischer Unterbau
Pro Veranstaltung kann nun die System-Mailadresse verändert werden (z.B. um als Absendermail „Veranstaltung XY“ erscheinen zu lassen).
Die Zeitläufe für Anträge und Änderungsanträge können nun bereits im Vorfeld festgelegt werden (bisher konnten die Funktionen einfach nur an/aus schalten).
Änderungsanträge durch die Originalantragstellenden übernehmen zu lassen, wurde bisher aufgrund der Komplexität (Kollisionen etc.) nicht gerne verwendet. Die Funktion wurde deutlich vereinfacht. Hierzu freuen wir uns weiterhin sehr über euer Feedback und Ideen.
Ein Plug-in-System wurde eingeführt, so dass künftig Erweiterungen hinzugefügt werden können, ohne dass das ganze System verändert werden muss.
Die Auswahl von Site-Layout und PDF-Layouts ist nun über kleine Vorschaubildchen statt über kryptische Namen möglich. Zugleich ist das PDF-Layout für Anträge etwas flexibler konfigurierbar als bisher. Die RSS-Feeds sind für Lesesysteme nun auto-discoverable.
Entfernt wurden das schwierig handhabbare und daher kaum genutzte separate Vorschaubild für Facebook sowie der veraltete alternative „Wurzelwerk“-Zugang (Grüne).
Zu guter Letzt wurde eine komfortable Exportfunktion für die Migration der persönlichen Daten eingeführt. Damit ist für Admins der Aufwand nach der DSGVO verringert und zugleich können Teilnehmende ihre Daten selbst jederzeit „mitnehmen“.
Vergangenes Wochenende konnten wir die neue Version 4.11 des ePartools veröffentlichen. Es handelt sich dabei um ein lange erwartetes Release, denn wir konnten die Installation und Ersteinrichtung drastisch vereinfachen.
Installation in 5 statt in 40 Minuten!
Bisher lief das Einrichten des ePartools für die meisten Admins folgendermaßen ab: Die aktuelle Version als ZIP-Paket herunterladen, auf dem eigenen Rechner entpacken und dann über ein SFTP-Programm die über .000 Dateien hochladen. Trotz schneller DSL-Verbindungen nahm das Hochladen rund 30 Minuten in Anspruch, da jede Datei separat aufgerufen und übertragen wurde.
Wir dachten uns, dass das doch schneller gehen muss: Wir präsentieren euch daher den neuen ePartool-Downloader – künftig muss nur noch eine einzige Datei zur Installation transferiert werden, die sich dann um das direkte Herunterladen und Entpacken auf den Server kümmert. Da der zeitraubende Umweg über euren heimischen Rechner damit wegfällt, startet der Einrichtungsassistent nun schon nach nur wenigen Sekunden.
Der ePartool-Downloader bietet weitere Vorteile:
Es wird immer die aktuellste Version des ePartools geholt.
Der ePartool-Downloader macht einen Kurzcheck mit eurem Server und gibt Tipps, wenn Probleme erkannt werden.
Eine häufige Fehlerquelle beim Installieren fällt weg: Gerade beim Installieren von Mac-Rechnern aus wurden versteckte Dateien, wie die .htaccess-Konfigurationsdatei im Hauptverzeichnis öfters mal übersehen und das ePartool konnte dann nicht in Betrieb genommen werden.
Ein Nachkonfigurieren für die Installation in Unterverzeichnisse ist in der Regel nicht mehr nötig.
Der ePartool-Downloader in Aktion
Selbstverständlich bieten wir weiterhin den traditionellen Weg an das ePartool herunterzuladen und selbst auf einen Server zu transferieren.
Eine Installationshürde stellte bislang auch die Einrichtung eines »Cronjobs« dar: Cronjobs sind Aufgaben, die der Server selbsttätig erledigt, egal ob sich gerade ein*e Besucher*in auf dem ePartool tummelt oder nicht. Das können z.B. Erinnerungsmails vor Ablauf des Voting-Zeitraums sein. Der Sicherheitskey für Cronjobs kann nun automatisch generiert werden, damit man sich nicht selbst einen ausdenken muss. Alternativ haben wir den sog. »Poor man’s cron« auch ins ePartool übernommen: Wer keine Cronjobs auf dem Webhosting einrichten kann, erhält damit zumindest eine etwas hemdsärmelige Notlösung: Jeder Besuch des ePartools, selbst wenn es nur der Bot einer Suchmaschine ist, löst im Hintergrund die Überprüfung auf ausstehende Aufgaben aus, so dass diese dennoch meist zeitnah ausgeführt werden.
Während des Installationsvorgangs wird eine Beispielbeteiligungsrunde eingerichtet, die dann nach eigenen Vorstellungen weiter gestaltet und verändert werden kann. Diese erste Beteiligungsrunde setzt nun Daten relativ zum Installationszeitpunkt, so dass die neue Beteiligungsrunde auch tatsächlich in der Zukunft liegt.
Gekümmert haben wir uns auch um die Altinstallationen, die auf die neueste Version des ePartools aktualisieren wollen. Eine ausführliche Installations- und Update-Anleitung findet sich wie bisher unter Installation / Download.
Mitgelieferte Grundeinstellungen, Beispieltexte und Datenschutz
Das ePartool möchte keine Nutzungsszenarien vorschreiben. Daher haben wir bei konzeptionellen Entscheidungen so weit wie möglich immer den offensten Weg gewählt. Allerdings haben wir zahlreiches Feedback von Trägern erhalten, die uns um vorformulierte (Lücken)texte baten. Diesem Wunsch sind wir nachgekommen, so dass das ePartool bei der Ersteinrichtung weitere Grundtexte zum Datenschutz, Impressum, FAQ, Hilfetexte und Systemmeldungen anlegt. Wichtig zu wissen: Diese neuen Texte werden bei einem Update nicht mit eingespielt – das ePartool soll keinesfalls eure selbst erarbeiteten Formulierungen überschreiben.
Neues beim Beitragen und zum Voting
Seit der Einführung von ortsbasierten Beteiligungsrunden vor gut einem halben Jahr haben wir Erfahrungen gesammelt und das System weiter verbessert. Sowohl auf der Admin-Seite wie auch sichtbar für die Teilnehmenden wurde die Landkartenfunktion verbessert und intuitiver gemacht. Das Einschränken auf eine von einem redaktionellen User zu definierende Region wurde im Backend besser erläutert.
Die Voting-Einstellungen im Backend wurden optisch deutlich verbessert und beinhalten für die verschiedenen Abstimmungstypen (Herzen, Sterne, Ja/Nein/Egal) sowie die Superbutton-Funktion Vorschaubilder.
Im Lauf der Jahre ist das ePartool sehr an Funktionen gewachsen. Damit man sich als Teilnehmer*in nicht von der Fülle der Funktionen und grafischen Elementen „erschlagen“ fühlt, arbeiten wir immer auch daran, Überflüssiges rauszuwerfen. Wir haben uns nun dazu entschieden, dass z.B. die schrägen „Jetzt Mitmachen“-Ribbons keinen Mehrwert in der Beitragen-Box oder Voting-Box bringen – man ist ja dann gerade schon dabei sich zu beteiligen. Die in schwarzem Hintergrund gehaltenen Ribbons wurden auch von Nutzer*innen in der Vergangenheit als „Trauerränder“ bezeichnet – also weg damit ;-).
Fehlerbehebungen und Aktualisierungen am System
Wir haben einen gelegentlich auftretenden Fehler, dass die Vorschaufunktion unter manchen Browser-/Betriebssystemkombinationen nicht zuverlässig funktionierte, behoben. Des Weiteren wurden einige externe Programmbibliotheken, auf die das ePartool zurückgreift (z.B. CKEditor), auf den aktuellen Stand gebracht.
Die arabische Sprache wird bisher im ePartool nur rudimentär unterstützt (Beiträge usw. sind möglich, einige Systemmeldungen sind übersetzt, aber die grafische Nutzeroberfläche ist noch nicht für Rechts-nach-Links-schreibende Sprachen vorbereitet); wir haben einen nächsten kleinen Schritt gemacht und als Standardschrift hierfür nun Droid Arabic vorgesehen.
Bekannte Probleme
Übersetzungen: In den vergangenen Monaten fanden sehr viele neue Funktionen und Programmlogiken Einzug in das ePartool. Leider sind dabei nicht alle Übersetzungen hinterhergekommen. Im administrativen Backend tauchen daher gelegentlich englische Meldungen auf, auch wenn die Sprache z.B. auf Deutsch eingestellt ist. Wir arbeiten daran, die Übersetzungen in den nächsten Wochen zu vervollständigen. Wer uns hierbei unterstützen will, ist herzlich willkommen! (einfach melden unter digital@dbjr.de)
Automatische Exportfunktion für alle Nutzerdaten: Die Datenschutz-Grundverordnung beinhaltet eine sinnvolle Idee, dass Nutzer*innen künftig leichter von einer Web-Plattform auf eine andere wechseln können. Dazu bedarf es einer Exportfunktion für alle persönlichen Daten. Wir haben hierzu zwar bereits einige Überlegungen angestellt und Vorkehrungen getroffen, allerdings haben wir bisher keine sinnvolles Format gefunden, wie Nutzende ihre Daten aus dem ePartool woanders hin transferieren möchten. Gerne hören wir von euren Vorschlägen!