[2.0.5] Download Plugin

 
koffeeinsuechtiger coding freak
Avatar
Geschlecht:
Herkunft: Neuss
Alter: 34
Homepage: fragz.de
Beiträge: 2216
Dabei seit: 03 / 2008
Betreff:

Re: [2.0.3] Download Plugin

 · 
Gepostet: 18.11.2017 - 15:43 Uhr  ·  #57
HiHo,

so eine Funktion, fest integriert im CF4 hat schon was.
Ansonsten wäre eine Plugin Lösung noch denkbar die in der Datenbank die entsprechenden Hookpoint auf hook_active = 0 setzt.
Könnte man als eigenständiges Plugin anbieten oder aber das die Pluginentwickler dieses direkt in Ihren Plugin integrieren.

Mal Abwarten was CBACK dazu sagt.

LG und schönes WE
Admin
Avatar
Geschlecht:
Herkunft: Saarland
Alter: 34
Homepage: cback.de
Beiträge: 17271
Dabei seit: 12 / 2003
Betreff:

Re: [2.0.3] Download Plugin

 · 
Gepostet: 20.11.2017 - 11:45 Uhr  ·  #58
Hallo Zusammen!

Zitat
oder aber das die Pluginentwickler dieses direkt in Ihren Plugin integrieren

Bingo! So ist das mit dem hook_active gedacht gewesen. :)


Aber ich fange mal ganz von vorne an, weil die kurze Frage hat eine etwas längere Antwort, ich muss ein bisschen ausholen, weil ich gerne so transparent wie möglich antworten möchte:

Funktion "Deinstallieren"
Hier steht tatsächlich schon eine kleine Änderung für auf meiner ToDo Liste für das nächste Update, nämlich, dass zum einen eine deutliche Sicherheitsmeldung vorgeschaltet wird, die erklärt, was bei der Deinstallation passiert, zum anderen auch ein deutlicherer Hinweis darauf, dass Plugin Updates keine vorherige Deinstallation erfordern. Die Funktion "Deinstallieren" gibt es eigentlich seit dem CF3 (2009) und bislang gab es da noch nie Schwierigkeiten mit. Ich bin auch ehrlich gesagt davon ausgegangen, dass der Begriff "Deinstallation" ansich auch jedem bekannt sein müsste, immerhin heißt das bei Computersoftware ja auch so und wenn man ein Programm deinstalliert sind natürlich auch die Arbeitsdaten bzw. Einstellungen weg - wenn dem nicht so ist, dann arbeitet ein Deinstaller eigentlich unsauber, da er Datenreste hinterlässt.

Damit es da aber keine Missverständnisse mehr gibt in Zukunft gibt es da dann mit dem nächsten Update wie gesagt eine deutlichere Sicherheitsrückfrage, in der auch deutlich darauf hingewiesen wird, dass selbstverständlich auch die Arbeitsdaten des Plugins Teil der Deinstallation sind. Das sollte dann künftig Bedienfehler an dieser Stelle ausschließen. Insbesondere wenn auch nochmal deutlicher signalisiert wird, dass beim Updaten von Plugins einfach Paket-hochladen ausreichend ist. Das macht es dann einfach besser verständlich in dem Bereich denke ich. :) Das wird aktuell vielleicht noch etwas unklar kommuniziert, aber das sind dann immer so kleine Punkte, die erst in der Praxis auffallen, aber dann natürlich bei Updates gerne auch verbessert werden. :)

Also da kommt auf jeden Fall was für Euch in dem Bereich! :)



Funktion "Deaktivieren"
Fragz hat es schon gefunden: Diese Funktion gibt es tatsächlich schon im CF4, allerdings wird die Nutzung dieser Funktion den Plugin Entwicklern überlassen, sofern sie nicht sogar einen eigenen Weg für so eine Funktion anbieten / integrieren möchten.

Dies hat eine Vielzahl von Gründen, warum das nicht direkt im Plugin-Panel integriert ist, obwohl es ja für mich auch nur ein 4-Zeiler im Code wäre, genau wie für Pluginentwickler, die sowas anbieten möchten (3 Zeilen um per DB den hook_active auf 0 zu setzen bei allen hooks mit dem Wert hook_module=Pluginordnername, 1 Zeile für $Cache->cache_drop(HOOKS); und beim aktivieren das selbe nur mit 1 statt 0).


Da es vielleicht gerade für die Entwickler interessant ist, gebe ich die Gründe für die Überlegung das nur im System vorzubereiten, aber nicht selbst auszuführen für alle Plugins pauschal mal gerne kurz an (vielleicht auch für den ein oder anderen Endanwender interessant, was "Behind the Scenes" manchmal so alles ausgeknobelt wird):

  • Klein-Plugins
    Es gibt beim CF4 sehr viele ... ich nenne es mal "klein Plugins", die zwar nicht unbedingt vom Code her klein sein müssen aber von der Art ihrer Funktion her gesehen. Solche Plugins erfüllen normalerweise nur eine einzige Funktion und sind aktiv, wenn sie installiert sind, und inaktiv, wenn sie deinstalliert sind. Da diese Plugins keine Arbeitsdaten besitzen ist es also egal wie oft man sie installiert oder deinstalliert. Ein Beispiel hierfür wäre z.B. der "CBACK TopicTags", der die Schlüsselwörter nicht speichert sondern aus dem Beitrag generiert. Es zeigte sich, dass durch das einfache Pluginsystem des CF viele Leute mal eine große Zahl an Plugins ausprobieren und sie hinterher doch nicht möchten und sie nicht wieder ganz entfernen. Eine Deinstallation setzt das Plugin dann wirklich komplett "auf halde" während bei einer deaktivierung doch immer noch Ballast für das Plugin im System mitgeschleppt wird. Die Möglichkeit Plugins einfach nur zu "deaktivieren" und sie damit für den Anwender in vergessenheit raten zu lassen, zeitgleich jedoch die Ausführung des Systems natürlich verlangsamen, auch wenn sie ignoriert werden (aktiv sind sie ja dann trotzdem noch) ist dann gegen das Performance Konzept des CF.

  • Verwechslungsgefahr "Deaktivieren" vs. "Deinstallieren"
    Teil dieses Gedankens ist natürlich die Verwechslungsgefahr der Begrifflichkeiten: Egal ob man Deaktivieren jetzt "ausschalten" nennt und Deinstallieren "löschen", damit die Wörter nicht all zu ähnlich sind (wobei es dann wiederum konflikt mit "komplett löschen" gäbe) ist das Risiko groß, dass Leute eben denken, wenn sie ein Plugin einfach nur deaktivieren ist das auch für das System gar nicht mehr interessant. Wie auch beim vorherigen Punkt wäre das aber ein falscher Gedanke für den Anwender, da deaktivierte Plugins trotzdem noch mitgeschleppt werden und ab irgend einer Masse die Ausführung des Systems dann ungewollt bremsen könnten.
    Wenn ein Plugin selbst jedoch eine Deaktivier-Funktion anbietet, dann braucht das Plugin dafür mindestens ein ACP-Modul - damit ist dem Anwender zumindest noch ersichtlich, dass ein Plugin durchaus noch mitläuft. Das macht es dann jedem klarer wie ich denke, dass auch bei einer Deaktivierung immer noch "irgend etwas" aktiv ist und lediglich eine Deinstallation wirklich das Plugin komplett auf das Abstellgleis setzt und das Forum sich dann gar nicht mehr darum kümmern muss bis es wieder installiert wird (unabhängig davon, ob man den Modulordner nun löscht oder nicht).

  • Pluginabhängigkeiten
    Beim CF4 ist es möglich, Plugins wiederum mit Plugins zu erweitern. Bei der Deinstallations-Routine kann ein Plugin Autor solche Abhängigkeiten vorher prüfen und sich auf das "installed" Flag bei voneinander abhängigen Plugins verlassen. Da bei deaktivierten Plugins dieses Flag gesetzt bleiben müsste (damit er nicht nochmal Zusatztabellen installiert) wäre das kein verlässlicher Ankerpunkt mehr. Voneinander abhängige Plugins könnten so versehentlich in falscher Reihenfolge deaktiviert werden und zu Problemen im System führen. Wenn ein Autor, der ein Plugin entwickelt, dort selbst jedoch eine Deaktivierung bereitstellen möchte wäre dieser Autor immer noch in der Lage selbst notwendige Prüfungen auszuführen. - Um dieses Problem zu umgehen müsste ansonsten jedes Plugin eine Funktion für deaktivierung / aktivierung und ggf. Abhängigkeitsinformationen verfügbar machen, damit eben das CF selbst, welches nicht alle Plugins kennen kann, wüsste, ob es sicher ist ein Modul zu deaktivieren oder nicht. - Und sobald ein Plugin Autor hier mal eine Angabe vergisst würde es zu Fehlern führen, die mitunter die Funktion des Systems stören. Also wäre das natürlich schlecht.

  • Plugins, die Daten im Betrieb loggen müssen
    Manche Plugins brauchen für ihre Ausführung selbst gewisse Logfiles oder Statusreaktionen, die für ihre korrekte Funktion notwendig sind: Beispielsweise wann jemandem zum letzten mal gratuliert wurde, wann Abodaten bearbeitet wurden, oder wer sich als letztes registriert hat etc. - Derartige Plugins dürften nie komplett deaktiviert werden, da zumindest die Hooks, die für das weitere Loggen von Daten zuständig wären aktiv bleiben müssten. Das Risiko, dass solche Plugins nach einer längeren "Pause" nach der Reaktivierung dann erst einmal "amok" laufen, weil sie versuchen, das "verpasste" wieder aufzuholen oder gewisse nötige Flags nicht gesetzt haben, die man bei einer Neuinstallation berücksichtigen könnte. Wäre dann natürlich auch schlecht.

  • Plugins mit alternativen Deaktiverfunktionen
    "Doppelt gemoppelt" ist im Bereich von Software nicht immer gut. Nur bei Backups. ;) - Das selbe gilt auch für Plugins, die getrennte Möglichkeiten haben, eine Deaktivierungsfunktion tatsächlich selbst zu erzielen. So gibt es beispielsweise in meinem Plugin "CBACK Welcome Post" einen An/Aus Schalter um das Begrüßen kurzzeitig zu stoppen. Beim Werbemanager gibt es Zeit-Flags und Deaktivier-Schalter für einzelne Banner. Und beim CBACK MediaManager kann man jede Funktion einzeln (und Gruppenberechtigungen) zu- bzw. abschalten und könnte auch so eine vollständige Deaktivierung erzielen ohne, dass Plugindaten verloren gehen. Hier wäre eine zusätzliche Deaktivier-Funktion dann natürlich redundant. Und wieder müsste ggf. das Plugin korrekt auf so einen Vorgang "von außen" reagieren, was mitunter Gefahren birgt, wenn sich mal am CF Core oder am Plugin etwas ändert.

  • Updateroutine
    Wenn ein Plugin bereits installiert ist und wird neu hochgeladen, dann wird es automatisch aktualisiert. Das geht aktuell sehr gut, weil der Autor im Updatesystem die Möglichkeit hat selbst Code auszuführen und im Zustand "deinstalliert" lediglich die Dateien ersetzt werden. Im Deaktivierten Zustand wäre jedoch die Gefahr gegeben, dass sich aktive und inaktive Hooks mischen bzw. das der Updater / der Autor immer auf einen zusätzlichen Pluginstatus reagieren müsste. Im Gegensatz zu einer eigenen Deaktivier-Funktion, wenn das eigene Plugin das verkraftet, wäre das natürlich vom Coding her in der package_setup wieder ein Zusatzaufwand - Und ich möchte eigentlich die Coding Guidelines so einfach wie möglich halten. Und selbst da gibt es gerade bei neuen Entwicklern immer mal Punkte die man noch nicht kennt. Das Risiko, dass ein Plugin also gerade auf so einen Zustand nicht richtig reagiert wäre bei einem Eingriff von außen in die Funktion also auch durchaus gegeben. Und das CF soll ja immer brav laufen. ;)



Neben den Überlegungen gibt es noch ein paar andere kleinere die mit zum Zug kamen, aber das würde jetzt zu weit führen. :D

Auf jeden Fall sollte damit hoffentlich klar sein, dass es keine Faulheit oder Weigern ist das nicht im Pluginpanel anzubieten und warum das dann doch auf die Pluginautoren ausgelagert wird. - Wie gesagt gibt es die Möglichkeit im CF ja schon und ist dann für Plugin-Autoren wirklich sehr sehr schnell zu realisieren. Im Grunde ist also 90% der nötigen Arbeit für so eine Funktion bereits im Core integriert und lediglich der Weg des "Freedom of Choice" für die Plugin-Autoren wurde als der effektivere (und sicherere) angesehen. :)


So das wurde jetzt länger als geplant, sorry fürs Missbrauchen des Download-Threads Karsten, kannst ja notfalls beim nächsten Update einen neuen Thread aufmachen, die alten schiebe ich dann ja immer weg. :) Aber vielleicht störts auch nicht, dass ich die Antwort auf den Vorschlag jetzt auch noch hier hingepackt habe. :D


Viele Grüße und eine schöne Woche,
Chris
Benutzer
Avatar
Geschlecht:
Alter: 57
Homepage: baremountain-forum…
Beiträge: 61
Dabei seit: 06 / 2017
Betreff:

Re: [2.0.3] Download Plugin

 · 
Gepostet: 20.11.2017 - 15:21 Uhr  ·  #59
Admin
Avatar
Geschlecht:
Herkunft: Saarland
Alter: 34
Homepage: cback.de
Beiträge: 17271
Dabei seit: 12 / 2003
Betreff:

Re: [2.0.3] Download Plugin

 · 
Gepostet: 21.11.2017 - 14:35 Uhr  ·  #60
Hi Mathias,

das mache ich doch sehr gerne!

Außerdem finde ich auch selbst (gerade in rein textbasierter Kommunikation) ein einfaches "nein gibts nicht" irgendwie unhöflicher als ein nein mit einer Begründung. Von daher, auch wenn die Antwort dann länger dauert, finde ich das einfach ein fairer Umgang mit den CF Nutzern. :)

LG,
Chris
Benutzer
Avatar
Geschlecht:
Alter: 57
Homepage: baremountain-forum…
Beiträge: 61
Dabei seit: 06 / 2017
Betreff:

Re: [2.0.3] Download Plugin

 · 
Gepostet: 21.11.2017 - 17:06 Uhr  ·  #61
Hi Chris,

Zitat geschrieben von cback

Hi Mathias,

das mache ich doch sehr gerne!

Außerdem finde ich auch selbst (gerade in rein textbasierter Kommunikation) ein einfaches "nein gibts nicht" irgendwie unhöflicher als ein nein mit einer Begründung. Von daher, auch wenn die Antwort dann länger dauert, finde ich das einfach ein fairer Umgang mit den CF Nutzern. :)

LG,
Chris


DAS zeichnet Dich ja auch aus. :)
Benutzer
Avatar
Geschlecht:
Herkunft: Irgendwo im Internet auf Server 127.0.0.1
Alter: 50
Homepage: oxpus.net
Beiträge: 2140
Dabei seit: 05 / 2004
Betreff:

Re: [2.0.4] Download Plugin

 · 
Gepostet: 24.03.2020 - 16:26 Uhr  ·  #62
So, Plugin wurde mal wieder aktualisiert.
Zwei Bugs verhinderten die korrekte Darstellung und Nutzung von Gästen.
Das wurde nun in Version 2.0.4 behoben.
Benutzer
Avatar
Geschlecht:
Herkunft: Irgendwo im Internet auf Server 127.0.0.1
Alter: 50
Homepage: oxpus.net
Beiträge: 2140
Dabei seit: 05 / 2004
Betreff:

Re: [2.0.4] Download Plugin

 · 
Gepostet: 11.04.2020 - 21:39 Uhr  ·  #63
Neues Update des Plugins mit diversen Fehlerkorrekturen und einem geänderten Bearbeitungsformular.
Version 2.0.5 ist ab sofort verfügbar.
Gewählte Zitate für Mehrfachzitierung:   0

Registrierte in diesem Topic

Aktuell kein registrierter in diesem Bereich

Die Statistik zeigt, wer in den letzten 5 Minuten online war. Erneuerung alle 90 Sekunden.