Error bei WBB4.1/WCF2.1 Plugin Updates auf Wbb4.0/WCF2.0

  • Affected App
    WoltLab Suite Core

    Hallo zusammen,

    ich nutze WBB 4.0 Version und möchte vorerst so lange dabei bleiben. Bis ich irgendwann alle Plugins die ich zurzeit nutze, updatefähig sind.
    Jetzt taucht aber mit einem Wbb4.0 Plugin eine Updatemeldung auf, weil es für die WBbb4.1 User ein Update gibt.
    Dieses Plugin wird laut Ersteller nicht mehr für das WCF2.0 weiter entwickelt, aber für WCF2.1 schon.

    Nun taucht bei mir eine Updatemeldung und wenn ich es updaten will, bekomme ich eine Fehlermeldung.
    Ausblenden kann ich diesen Plugin Update auch nicht. Kann das bitte behoben werden?

  • Wo ist denn da der Fehler? Wenn der Entwickler das Paket nur fürs WCF 2.1 bereitstellt, dann ist es doch logisch, dass es nicht im WCF 2.0 funktioniert. Oder verstehe ich jetzt was falsch?

    EDIT: Sorry, missverstanden, du möchtest wohl einfach nicht, dass das Update auftaucht.

  • Seh ich das richtig das du von 2.0.7 auf 2.0.12 Updaten willst und das WCF automatisch auf 2.1 gehen will welches nicht unterstützt wird weil diese Version für das WCF 2.1 ist?

  • Er möchte vermutlich eher von Version 2.0.6pl4 auf 2.0.7 updaten (Versionsnummern vom Plugin) und das 2.0.7er Update ist nur fürs WCF 2.1, taucht aber als Update in einem WCF 2.0 auf und verursacht dann natürlich diese Fehlermeldung.

  • Ja ist schon richtig :) Dies Plugin wir nicht mehr für WCF 2.0 weiterentwickelt, nur für das WCF 2.1.
    Nun taucht eine Updatemeldung bei mir auf, ich soll bitte auf die nächste Version Updaten.

    Geht aber nicht weil der ich keine WCF 2.1 Version habe, nun bleibt die Updatemeldung ständig eingeblendet.

    Wundert mich, das sich bisher keine anderen User gemeldet haben, das nervt doch total.

    Hier steht mehr dazu:

    woltlab.com/pluginstore/file/1650/
  • Das sind die Plugin-Autoren selbst Schuld, wenn sie für neue WCF- und/oder WBB-Versionen kein neues Plugin veröffentlichen und stattdessen im Pluginstore Paketversionen für verschiedene Systeme vermischen... Ich persönlich kritisiere dieses Vorgehen aus einer Vielzahl von Gründen und würde es selbst nicht so handhaben.

  • Das sind die Plugin-Autoren selbst Schuld, wenn sie für neue WCF- und/oder WBB-Versionen kein neues Plugin veröffentlichen und stattdessen im Pluginstore Paketversionen für verschiedene Systeme vermischen... Ich persönlich kritisiere dieses Vorgehen aus einer Vielzahl von Gründen und würde es selbst nicht so handhaben.

    An dieser Stelle möchte ich mich einmal einklinken. Warum siehst du das so?

    Meine Plugins funktionieren z.B. sowohl im WCF 2.0 als auch im 2.1 zum größten Teil. Es macht für mich also wenig Sinn, diese in unterschiedlichen Versionen hochzuladen. Aber nehmen wir jetzt mal an, ein Plugin benötigt ein Update, um WCF 2.1 kompatibel zu sein. Warum sollte ich dies dann als neues Plugin hochladen? Gerade bei kommerziellen Plugins geht das überhaupt nicht, weil Bestandskunden dann keinen Zugriff mehr haben. Und selbst bei freien Plugins ist es ja doch eine neue Version, und kein gänzlich neues Plugin, welches ich da erstellt habe. Außerdem verliert man dann sämtliche Kommentare und Likes - das ist, gerade wenn man "nur" ein Kompatibilitätsupdate anbietet, nicht erstrebenswert, da gerade die Kommentare oft sehr hilfreich sind.

    Vielmehr sollte imho WoltLabs Paketserver-Integration dafür Sorge tragen, dass in dem 2.0 Paketserver keine Updates ausgeliefert werden, die WCF 2.1 benötigen. Dann würde das Problem gar nicht erst auftauchen.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Mir geht es nicht um die Plugins, die mit beiden Versionen des WCF kompatibel sind, sondern um einzig um jene, die aus Kompabilitätsgründen in min. zwei Versionen zur Verfügung gestellt werden müssen.

    Ich persönlich lege recht viel Wert auf Ordnung und Ordnung definiere ich in Bezug auf den Pluginstore so, dass ein Plugin, welches ausschließlich mit dem WCF der Version X kompatibel ist, auch als seperates Paket für Version X zur Verfügung gestellt werden müsste. Genau so, wie m.M. auch jede Kompabilitätsversion eines Plugins einen eigenen Paketbezeichner benötigt und es sich per Definition dann nicht mehr um das selbe Plugin handelt.

    Zumindest so lang der Pluginstore und der Paketserver so funktionieren, wie sie funktionieren.

  • Genau so, wie m.M. auch jede Kompabilitätsversion eines Plugins einen eigenen Paketbezeichner benötigt

    Hier komme ich nicht mit. Warum sollte eine Kompatibilitätsversion einen neuen Paketbezeichner benötigen, wenn es exakt dieselbe Funktion hat wie vorher?

    Ich persönlich finde es viel ordentlicher, ein Plugin, das Funktion X hat, bei einer Eintragung zu belassen – für alle Versionen, die es gibt. Solange die Funktion selbst nicht geändert wird, sehe ich keinen Grund, warum das als neues Plugin dargestellt werden soll.

  • Da ich vor genau dem selben Problem stehe, antworte ich mal für den TE:

    Man könnte jetzt meinen, dass das Update von http://updates.foren-verbund.net/ abgerufen wird, dieser Server ist allerdings derzeit bei mir nicht erreichbar.

  • Hey Sascha, was wäre den die Lösung dafür? Server einfach abschalten


    Server entfernen und manuell neu anlegen. Danach "Updates suchen".

    Holzhammer
    SQL
    SET foreign_key_checks = 0;
    TRUNCATE TABLE wcf1_package_update_version;
    TRUNCATE TABLE wcf1_package_update_requirement;
    TRUNCATE TABLE wcf1_package_update_optional;
    TRUNCATE TABLE wcf1_package_update_fromversion;
    TRUNCATE TABLE wcf1_package_update_exclusion;
    TRUNCATE TABLE wcf1_package_update;
    UPDATE wcf1_package_update_server SET lastUpdateTime = 0, status = 'online', errorMessage = NULL;
    SET foreign_key_checks = 1;


    Danach ggf. Cache leeren und "Updates suchen".

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!