LSR-Protest-Plugin

[mattsches]

Hallo,

nachdem das Leistungsschutzrecht jetzt den Deutschen Bundestag passiert hat, bin ich an die Domain-Blacklist von D64 erinnert worden, für die es schon seit einer Weile ein Wordpress-Plugin gibt. Ich habe das Plugin mal nach S9y portiert und noch etwas verbessert. Alle Infos gibt's hier auf GitHub, für Hintergrundinformationen folgt ihr den Links dort.

Es gab die Anfrage, das Plugin über Spartacus bereitzustellen, also zu den additional_plugins hinzuzufügen. Ich möchte das momentan eigentlich nicht, u.a. weil das Plugin

• nur für deutsche Blogs sinnvoll ist;

• möglicherweise irgendwann nicht mehr gebraucht wird (auch wenn ich nicht daran glaube, dass das bald der Fall ist);

• noch nicht fertig ist (z.B. werden Links im Feed noch nicht umgeleitet, das fixe ich aber noch).

Wer will kann sich das Plugin manuell installieren, muss dann aber bei Aktualisierungen wieder selbst ran. Wenn ein großer Teil der Community aber der Meinung sein sollte, das Plugin müsse unbedingt in Spartacus - an mir soll's nicht scheitern

[onli]

Ich hätte es gerne in Spartacus, weil es die Installation und das Updaten so viel einfacher macht - besonders letzteres ist mir für meinen Blog wichtig, da es mit den Links ja an einer kritischen Stelle rumwerkelt. "Es ist noch nicht fertig" halte ich dagegen für ein gutes Argument, vor allem wenn du gerade daran aktiv arbeitest.

Zu den anderen:

nur für deutsche Blogs sinnvoll ist;

Stimmt erstmal, aber das kann man kennzeichnen und wir haben eben eine eher deutsche Nutzerbasis (soviel ich weiß)

möglicherweise irgendwann nicht mehr gebraucht wird (auch wenn ich nicht daran glaube, dass das bald der Fall ist);

Das wäre schön :-) Aber ich glaube, das wäre kein Argument gegen Spartacus-Integration. Bezüglich svn/cvs bin ich nicht so fit, aber meines Wissens war es bei denen ein Problem, Dateien zu entfernen, bei git ist es aber keines. Und die Blacklist aktualisiert sich ja sowieso.

[bernd_d]

Vielleicht hat unser Bundespräsident ja ein Einsehen und unterschreibt den Quatsch nicht, dann wäre das Plugin eh erstmal hinfällig.

Zumindest glaube ich, dass unser Rechtssystem so aufgebaut war, dass am Ende der Bundespräsident jedes Gesetz erst unterschreiben muss, damit es rechtskräftig wird. Allerdings glaube ich nicht so recht daran, dass er sich da verweigern würde.

[yellowled]

nur für deutsche Blogs sinnvoll ist

Das könnte man ja in der Beschreibung des Plugins anmerken. Ebenso könntest Du es, so lange es noch nicht fertig ist, als „proof of concept“ markieren.

möglicherweise irgendwann nicht mehr gebraucht wird

Das gilt für andere Plugins auf Spartacus jetzt auch schon.

Es würde die Nutzerbasis und damit die Anzahl der Tester vermutlich erhöhen, wenn es auf Spartacus wäre. Mir fällt an und für sich kein guter Grund ein, warum es nicht auf Spartacus liegen sollte …

YL

[mattsches]

Hmm, na gut, überzeugt. Sobald ich die offenen Tasks fertig habe, schiebe ich es nach additional_plugins rüber

[mattsches]

Ok, hab's gerade committet und gepusht. Sagt Bescheid, falls es Probleme gibt.

[refilix]

Hallo,

danke für dieses Plugin. Hatte schon gegrübelt wie man nun mit Links umgehen soll wo man nicht so recht weis ob man Rechte verletzt oder nicht.

Grüße refi

[onli]

Ich habe die Probleme mit dem entryproperties-Plugin noch ein bisschen untersucht:

Habe vorhin nochmal getestet und tatsächlich ist es der entryproperty-cache - sobald der deaktiviert wird, springt das LSR-Plugin an und ersetzt die Links.

Das serendipity_event_entryproperties-Plugin habe ich leider noch nie wirklich kapiert. Bin nochmal in den Code gegangen: Wenn ich das richtig sehe, speichert das beim Speichern die Version des Artikels nach Anwenden der Markup-Plugins. Beim Anzeigen wird des Eintrags, via frontend_fetchentries-hook, wird dann dieser gespeicherte Text aus der Datenbank geholt - allerdings sehe ich nicht, an welcher Stelle verhindert wird, dass der vom LSR-Plugin genutzte frontend_display-Event ausgeführt wird.

Entweder ist das im Core eingebaut, oder ich übersehe es im Plugin, oder es wird gar nicht unterdrückt, sondern nur der Text nachher ersetzt.

Laut Garvins Buch sollte es im Backend einen Eintrag "Einträge -> Cachen aller Artikel" geben, mit dem man den Cache aktualisieren könnte - tatsächlich sind im Plugin auch entsprechende Funktionen, aber den Menüpunkt finde ich nicht. Den Code für den Menüpunkt schon, scheint kaputt zu sein oder ich bin betriebsblind.

Auf jeden Fall war meine Lösung nun, das entryproperties-Plugin zu deaktivieren. Ich hoffe, dass das simple_cache-Plugin ausreichend cached (obwohl es die Änderung des LSR-Plugins instant umsetzte), um das entryproperties-plugin zu ersetzen. Die anderen Funktionen des Plugins nutze ich meines Wissens nicht (es ist ja stark genug im Core eingebaut, dass ich mir dessen nicht ganz sicher sein kann).

[bernd_d]

Das entry... bzw. Core hat so mit dem Cache wohl seine Probleme, siehe auch meine Probleme in http://board.s9y.org/viewtopic.php?f=3&t=19081, dass der Cache aus der Datenbank verwendet wurde, obwohl das Plugin gar nicht (mehr) installiert war.

[Timbalu]

Laut Garvins Buch sollte es im Backend einen Eintrag "Einträge -> Cachen aller Artikel" geben, mit dem man den Cache aktualisieren könnte - tatsächlich sind im Plugin auch entsprechende Funktionen, aber den Menüpunkt finde ich nicht. Den Code für den Menüpunkt schon, scheint kaputt zu sein oder ich bin betriebsblind.

Einfach in der Backend Seitenleiste schauen. Der Link ist so ziemlich unabhängig vom Plugin.
< a href="?serendipity[adminModule]=event_display&serendipity[adminAction]=buildcache">Cachen aller Artikel</a >
Dort kann man - wenn man es weiß - diesen entryproperties cache für alle entries erneut anstoßen, sobald man irgendein Plugin installiert hat, das die Einträge verändern will. (So verstehe ich das zumindest.)

[onli]

Der Link existiert bei mir nicht. Ist der bei euch allen wirklich im Admin-backend unter Einträge? Dann würde es an meinem Template liegen.

Bernd, danke für den Hinweis, da muss ich also doppelt drauf achten.

[Timbalu]

Good catch!
Ich habe auch zwei verschiedene Installationen.... Meines Erachtens hat das entryproperties einen bug, indem es mit $serendipity['userlevel'] auf die falsche Variable checkt. Es müsste $serendipity['serendipityUserlevel'] heißen! (~572).
Warum das aber bei meiner alten 1.6.1 scheinbar arbeitet, aber bei weiteren Neuinstallationen zB nicht, erschließt sich mir vorerst nicht so recht..., denn $serendipity['userlevel'] wird nirgendwo anders benutzt, ist aber in meiner alten Installation doch mit dem korrekten USERLEVEL_ADMIN belegt. Das ist dann bei den anderen Installationen mit 1.7 nicht mehr der Fall.

[onli]

Ah, gut, die Zeile kam mir auch komisch vor, aber von dem Rechtesystem hab ich zuwenig Ahnung. Danke fürs Testen! Du hast schon einen Patch commitet?

[Timbalu]

Ja, vorerst ein mal nur in die master RC4... mal sehen ob Garvin das näher erklären kann...

[bernd_d]

Was mir eben aufgefallen ist: ChangeLog wird (im Gegensatz zu anderen Plugins) nicht im Browser geöffnet, sondern immer als Download angeboten. Wäre schön, wenn man das ändern könnte.