Das ist nicht möglich und wenn, muss jeder Drittanbieter selbst dafür sorgen.
Ist jetzt mehr als 1 Jahr alt:
Das ist nicht möglich und wenn, muss jeder Drittanbieter selbst dafür sorgen.
Das liegt dann aber am Design des WSCs... Denn andere Frameworks und die Konkurrenz kann das nämlich.
Das liegt dann aber am Design des WSCs... Denn andere Frameworks und die Konkurrenz kann das nämlich.
Das kann gut sein, ich habe auch nichts gegenteiliges behauptet. Aber die Architektur der WoltLab-Software lässt das seit jeher nicht zu und macht es notwendig, dass die Entwickler da selbst tätig werden. Andererseits ist das auch nur bis zu einem gewissen Grad möglich.
Das kann gut sein, ich habe auch nichts gegenteiliges behauptet. Aber die Architektur der WoltLab-Software lässt das seit jeher nicht zu und macht es notwendig, dass die Entwickler da selbst tätig werden. Andererseits ist das auch nur bis zu einem gewissen Grad möglich.
Ja, es würde aber den Upgradeprozess vereinfachen, da man diese EAs einfach deaktiviert.
Deinstallation heisst auch gleich immer Datenverlust... beim Deaktivieren bleiben die Daten da, bis eben ein Update der EA da ist... und selbst wenns keins kommt, kann man sich die Daten noch aus der DB holen.
Das würde das WSC doch noch ein Stpck attraktiver machen, finde ich...
Ist jetzt mehr als 1 Jahr alt:
das war mir entgangen, wurde auch nicht als "bereits vorhanden" angezeigt in den "ähnlichen Themen", sonst hätte ich den Kommentar da ja direkt drunter setzen können 
Das kann gut sein, ich habe auch nichts gegenteiliges behauptet. Aber die Architektur der WoltLab-Software lässt das seit jeher nicht zu und macht es notwendig, dass die Entwickler da selbst tätig werden. Andererseits ist das auch nur bis zu einem gewissen Grad möglich.
Ok DAS wusste ich so nicht, das die WL-Struktur das nicht zulässt, wo sind denn da die Einschränkungen? vlt. sind die gar nicht sooo groß @"bis zu einem gewissen Grad möglich"
weil ich die Pakete desinstallieren musste, muss ich nun bei 20 Paketen hinter rennen um zu sehen ob es da inzwischen 5.2er Versionen gibt ..
darum dachte ich wäre das nützlich, wenn man die die im Weg stehen einfach deaktiviert und nach dem Update dann aktualisiert ..
wenn das die Grundlegende Struktur nicht zulässt .. wie gesgt das wusste ich vorher nicht, aber als Idee fand ich das erwähnenswert
das war mir entgangen, wurde auch nicht als "bereits vorhanden" angezeigt in den "ähnlichen Themen"
Die Standardeinstellung für Ähnliche Themen ist 365 Tage. Da das "Ähnliche Thema" älter als 365 Tage ist, wird es Dir auch nicht vorgeschlagen
das war mir entgangen, wurde auch nicht als "bereits vorhanden" angezeigt in den "ähnlichen Themen", sonst hätte ich den Kommentar da ja direkt drunter setzen können
Ok DAS wusste ich so nicht, das die WL-Struktur das nicht zulässt, wo sind denn da die Einschränkungen? vlt. sind die gar nicht sooo groß
weil ich die Pakete desinstallieren musste, muss ich nun bei 20 Paketen hinter rennen um zu sehen ob es da inzwischen 5.2er Versionen gibt ..
darum dachte ich wäre das nützlich, wenn man die die im Weg stehen einfach deaktiviert und nach dem Update dann aktualisiert ..
wenn das die Grundlegende Struktur nicht zulässt .. wie gesgt das wusste ich vorher nicht, aber als Idee fand ich das erwähnenswert
Was für einen Vorteil hat das aktivieren bzw deaktivieren? Wenn die plugins noch nicht für die neue Version sind, sollte man in Hinblick auf mögliche Probleme das Update noch abwarten. Denn das deaktivieren bringt einem effektiv ja nichts, wenn es ein plugin ist welches eigentlich genutzt bzw gebraucht wird, will ich es doch nicht deaktivieren sondern so lange nutzen bis alle plugins auf 5.2 bereit sind.
Habe mich auch erst gefragt, welchen Nutzen das haben soll.
Aber nun habe ich verstanden was du meinst.
Man hat 20 Plugins, von den es zwar Updates für die neue WSC gibt, diese sich aber nicht alle vor dem WSC-Update aktualisieren lassen.
Will man nun das WSC updaten, werden z.B. 10 davon als inkompatibel mit dem Updaten genannt.
Also muss man deinstallieren, obwohl alle (nach Update der einzelnen Pakete) lauffähig wären.
Könnte man die deaktiviren und nach WSC-Update ebenso update, hätte man keine Datenverluste.
So war es gemeint, oder?
Display MoreHabe mich auch erst gefragt, welchen Nutzen das haben soll.
Aber nun habe ich verstanden was du meinst.
Man hat 20 Plugins, von den es zwar Updates für die neue WSC gibt, diese sich aber nicht alle vor dem WSC-Update aktualisieren lassen.
Will man nun das WSC updaten, werden z.B. 10 davon als inkompatibel mit dem Updaten genannt.
Also muss man deinstallieren, obwohl alle (nach Update der einzelnen Pakete) lauffähig wären.
Könnte man die deaktiviren und nach WSC-Update ebenso update, hätte man keine Datenverluste.
So war es gemeint, oder?
ganz exakt so war das gemeint, wenn man die deaktivieren könnte und nach dem update ggf. hachholen könnte, wäre das Ziel erreicht, die sollen eben nur noch in dem Moment wo ein Update auf die 2. Stelle(5.3) (oder 1. Stelle (6.0) ) es erfordern würde im Weg stehen so wie eben bei der 5.1 auf 5.2 bei mir gewesen ..
Die EventListener und Templatelistener könnte man eventuell noch umgehen.
Beim Routing könnte man eventuell auch die Paketzugehörigkeit der Seiten prüfen.
Problematisch wird es dann, wenn Foreign Keys im Spiel sind.
Löscht das WSC eine referenzierte Spalte oder ändert den Datentyp, knallt es - egal ob deaktiviert oder nicht.
Es reicht auch, wenn das WSC eine entsprechende Tabelle entfernt oder eine Spalte erstellt, die ein anderes Paket bereits erstellt hat.
Also eigentlich sollten sich doch alle Pakete auf die aktuelle Version updaten wenn man das 5. 2 Update macht. Also bei mir ging das
Alle Updateserver eintragen und dann updaten, die Pakete von den Drittanbietern sind automatisch geupatet worden während mein wsc auf 5.2 ging. Wobei viele Hersteller, wie UdoZ seine plugins für 3.1 und 5.2 kompatibel gemacht hat, damit die Updates leichter werden.
3.1 und 5.2 kompatibel gemacht hat, damit die Updates leichter werden.
Das sehe ich ebenso.
Oft liegt es am Plugin Ersteller der es einfach möglich macht.
Und wenn jemand es "deaktiviert" haben möchte, kann er ja in der Datenbank die Abhängigkeit ändern.
Dennoch gilt dann generell keine "Haftung"... Man kann ja auch geduldig sein und warten bis die PLugins für die neue Version vorhande sind.
Ja, es würde aber den Upgradeprozess vereinfachen, da man diese EAs einfach deaktiviert.
Na ja, aber nur für den Anwender. Als Entwickler, egal, ob nur Woltlab oder nicht klingt das für mich schon sehr anspruchsvoll. Ich möchte z.B. auch keinen Datenschrott mit mir im System herum schleppen, weil ich da noch irgendwo Softwareteile habe, die nicht funktionieren.
und selbst wenns keins kommt, kann man sich die Daten noch aus der DB holen.
Dafür kannst du auch einfach die Tabellen sichern, das ist für mich kein Argument. In ein PlugIn neuer Version rein kriegst du die dann trotzdem nicht einfach so. Manchmal kann man es selber recht leicht übernehmen, aber wenn globale Tabellen/Schlüssel mit betroffen sind, wird schwieriger.
weil ich die Pakete desinstallieren musste, muss ich nun bei 20 Paketen hinter rennen um zu sehen ob es da inzwischen 5.2er Versionen gibt ..
Na ja, du wirst wohl immer nachsehen müssen, ob es Pakete für die neue Version gibt. Sonst wunderst du dich wohl danach, das nichts mehr funktioniert wie vorher.
Ich kenne kein System das das so von Haus aus kann. Nennt ihr mir mal ein paar Beispiele? Finde ich interessant.
Ich kenne kein System das das so von Haus aus kann. Nennt ihr mir mal ein paar Beispiele?
Du meinst, Plugins deaktivieren zu können statt die deinstallieren zu müssen? Mir fallen da sofort, ohne lange drüber nachzudenken, WordPress und Pimcore ein. Ich bin mir ziemlich sicher, dass es da noch einige weitere Beispiele gibt.
Ich kenne kein System das das so von Haus aus kann. Nennt ihr mir mal ein paar Beispiele? Finde ich interessant.
Wie Cadeyrn schon schrieb, ist Worpress sicher eines der prominetesten Beispiel, aber auch der Communitybereich kann das... Siehe hier, in dem ich per einem Klick mal kurz den Kalender deaktviert habe.... Alles Stock !
Danke, da muss ich mir WordPress vielleicht doch mal ansehen :D, wobei ich eigentlich froh bin, wenn ich so einen Datenschrott nicht mit herum schlepppen muss. PlugIns deinstallieren macht aber natürlich auch mir keinen Spaß.
Welches System ist das TheSonic ?
Gut fände ich hier bei Woltlab zumindest eine sprechendere Fehlermeldung als diese typischen Systemmeldungen. Vielleicht noch mit einem Hinweis, wie man vorgehen muss, um auch alle PlugIns zu updaten. In der Updateanleitung fehlt das ja leider komplett. Also ungefähr so:
Das Paket hastnnichtgesehen ist nicht mit der gewünschten Coreversion kompatibel. Bitte prüfen Sie vor dem Upgrade, ob für Softwarepakete von Fremdanbietern Updates auf diese Coreversion vorhanden sind. Sofern sie vorhanden sind, richten Sie bitte die entsprechenden Paktserver der Fremdanbieter ein. Sind sie nicht vorhanden, deinstallieren Sie bitte das jeweilige Paket vor einem erneuten Upgradeversuch.
Das könnte schon viele Fragen und einigen Frust mindern, denke ich.
Alternativ könnte man auch eine Routine vorschalten, die gesammelt für die ganze Installation prüft und das Ergebnis ausgibt.
Welches System ist das TheSonic ?
Invision
Don’t have an account yet? Register yourself now and be a part of our community!
