event und sidebar plugin verbinden

[Timbalu]

Hi

Kann man ein event plugin mit seinem sidebar plugin so verbinden, dass beide auf dieselben config settings zugreifen können?
Ich hatte den Fall gerade mit "approved", wo ich lernen musste, dass beide dies als Einstellung in der config benötigen, um mit get_config('approved') abgerufen zu werden. Klarer Denkfehler natürlich, aber vielleicht gibt es ja eine Einstellung aus den Untiefen der API mit der dies trotzdem möglich ist.

Dabei fällt mir gerade auch noch ein, dass ich zu dependencies keine doku außer polnisch finden konnte.
Ich hätte gerne gewußt, wo onli das "hold" her hat...

Ian

[onli]

Ich hätte gerne gewußt, wo onli das "hold" her hat...

Aus einem anderen Plugin, ich glaube sogar aus einem von meinen. Woher das wiederum kam weiß ich nicht. Vll hat es Garvin mal geschrieben.
Bin mir aber auch geraden nicht sicher, ob das funktioniert. Ich habe gerade in meinem Blog das Autoupdater-Plugin installiert und das dashboard wurde definitiv nicht mitinstalliert. Finde es gerade frustrierend, dass das Abhängigkeitssystem so unzuverlässig ist :/ (Außer "hold" existiert schlichtweg nicht, dann liegts wohl daran).

[Timbalu]

doch, doch, es gab noch "keep" und "nochirgendetwas"... wenn ich mich recht erinnere...
Eine Abhängigkeit muss ja nicht gleich auch ein automatisches mit-Install sein, oder?

Ian

Edit:
gerade gefunden im adduser plugin
// Register (multiple) dependencies. KEY is the name of the depending plugin. VALUE is a mode of either 'remove' or 'keep'.
// If the mode 'remove' is set, removing the plugin results in a removal of the depending plugin. 'Keep' meens to
// not touch the depending plugin.

das würde bedeuten, dass ein install gar nicht beabsichtigt ist.

Edit2:

But you can create a event plugin within the same directory and load that via the $this->dependencies() array.

wenn dein plugin ein sidebarplugin wäre, ginge es wohl damit....

Edit3:
Wenn nicht das Problem bliebe, dass dein Plugin erst noch automatisch durch Spartacus heruntergeladen werden müsste, könnte wir es möglicherweise so per dashboard aktivieren.

Code: Select all

serendipity_plugin_api::create_plugin_instance('serendipity_event_autoupdate', null, 'event');

Was sagt Garvin dazu?

[garvinhicking]

Hi!

Also theoretisch solllte das funktionieren, auch wenn der Code glaub ich nur "keep" oder "remove" (nicht "hold") verwendet. Wenn das praktisch nicht funktioniert müsste man das natürlich einmal debuggen und schauen ob da irgendwo ein Fehler, gerade in Zusammenarbeit mit Spartacus, vorhanden ist.

Beim adduser plugin ist das ja nicht so tragisch, da werden beide "abähngigen" plugins per spartacus in einem rutsch runtergeladen.

Gemeinsam auf dieselben Configs zugreifen geht nur per direktel Zugriff auf die serendipity_config tabelle; bzw. wenn mans per API machen will muss man das aus $serendipity fischen, da müsste die liste und config aller event plugins drin sein.

Grüße,
Garvin

[Timbalu]

Nun ja, falls ich dass richtig verstehe bedeutet dies, wenn remove=false, wird das dependencies plugin mit function autodetect_instance aufgerufen, welches wiederum serendipity_plugin_api::create_plugin_instance also den plugin install aufruft. Das wäre auch alles richtig, wenn das autoupload plugin mitgeliefert und damit im array $classes wäre.
Es bleibt also ein Problem des Downloads...!

Wobei mir immer noch nicht klar ist, wie $this->dependencies mit register_dependencies() zusammenhängt..., oder ist das der Fehler?

Ian

[Timbalu]

Ich muss darauf noch einmal zurückkommen, Garvin.

Gemeinsam auf dieselben Configs zugreifen geht nur per direktel Zugriff auf die serendipity_config tabelle; bzw. wenn mans per API machen will muss man das aus $serendipity fischen, da müsste die liste und config aller event plugins drin sein.

Ja das schon, nur leider mit dieser speziellen instance id, an die ich automatisch ja so nicht rankomme, oder?

Code: Select all

[serendipity_event_guestbook:c3988k4571f54fb9fba3f6fdc2d7he1d/approve] => 1

Während ich das so betrachte, fiel mir ein, dass ich ja eventuell ein

Code: Select all

$this->dependencies = array('serendipity_event_guestbook' => 'keep');

in das sidebar plugin setzen könnte.

Kannst du mir nun sagen, ob ich damit möglicherweise die selbe instance ID für das event und das sidebar plugin in der config tabelle generiere? Damit ließe sich mein Problem dann doch irgendwie abfangen....

Oder ob mir soetwas

Code: Select all

$keys[] = serendipity_plugin_api::autodetect_instance('serendipity_event_guestbook', 255, true);

das Gesuchte eventuell herbeizaubern kann?

[garvinhicking]

Hi!

Wenn du einen Wert ganz konkret auslesen willst, würde ich eine Datenbankabfrage machen auf serendipity_config und da einfach nach serendipity_eent_guestbook:%/configname suchen. Das geht schneller als mit PHP das ganze $serendipty durchzulaufen und auf jeden $key einen regulären Ausdruck anzuwenden, schätze ich.

Das autodetect_instance tut vermutlich etwas ähnliches...

Die instance-IDs werden bei der installation eines plugins zufällig vergeben und gespeichert, udn die sind immer unique. Also auch bei gekoppelten plugins kommt die ID nicht mehrfach vor...

[Timbalu]

Wenn du einen Wert ganz konkret auslesen willst, würde ich eine Datenbankabfrage machen auf serendipity_config und da einfach nach serendipity_eent_guestbook:%/configname suchen. Das geht schneller als mit PHP das ganze $serendipty durchzulaufen und auf jeden $key einen regulären Ausdruck anzuwenden, schätze ich.

Tja danke, dahinter bin ich auch vor ner Weile gekommen. Leidvoll, muss ich zugeben, da ich noch immer mit Aufräumarbeiten beschäftigt bin, ....

Das autodetect_instance tut vermutlich etwas ähnliches...
Die instance-IDs werden bei der installation eines plugins zufällig vergeben und gespeichert, udn die sind immer unique. Also auch bei gekoppelten plugins kommt die ID nicht mehrfach vor...

da ich deine Antwort nicht abwarten konnte und es einfach mal mit nem anderen pluginnamen probiert habe.
Oh Gosh! Finger wech davon, kann ich nur sagen Aber wieder was gelernt!

[Timbalu]

Hi Garvin

Ich habe da jetzt eine gute Lösung gefunden, bei der sich eine weitere kleine, aber davon unabhängige, Frage abzeichnet.

Beim Speichern der Plugin Config, überprüfe ich im 'backend_configure' hook einen möglichen config mismatch, bei dem, falls erforderlich, eine config var wieder auf default zurück gesetzt wird.
Wie bekomme ich nun meine Fehler-Informations-Ausgabe in diese Speichermeldung des Submits hinein?

Code: Select all

Fertig: Die neuen Einstellungen wurden um 18:48:31 gespeichert.

Leider zeigt die Config auch erst nach einem Reload die geänderte Option richtig an.

[garvinhicking]

Hi!

Hm, dafür wäre eigentlich eher die cleanup() methode gedacht, die beim Speicher aufgerufen wird. backend_configure greift BEVOR dein plugin überhaupt die änderungen speichert, wäre das gewollt? Eine Fehlermeldung kriegst du so nicht unter, die müsstest du dann irgendwo in einer Hilfsvariable speichern und bei cleanup() dann ausgeben.

Grüße,
Garvin

[Timbalu]

Ah ja, cleanup löst die Sache absolut gut und die Error Ausgabe geht genau dahin wo sie hin soll
Klasse, Danke.