You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are now some depreciated modules. There is a need to manage them.
Zum Beispiel ersetzt mein neues Modul hh-historic-events vier andere Module. Es sollte nicht passieren, dass sowohl das neue als auch die alten Module gleichzeitig installiert sind. Dasselbe gilt für die drei neuen Favicon-Module, von denen immer nur eines aktiv sein soll. Oder das mtv-Nachfolge-Modul von huh. Aber es gibt auch Module ohne Alternative, die aus anderen Gründen nicht mehr aktiv sein sollten, etwa Tolopla aus Datenschutzgründen oder Module, die in den webtrees-Kern übernommen worden sind und deshalb nicht mehr zusätzlich aktiv sein sollen.
o.k., generell macht das für mich Sinn. Ich muss mir aber erst einmal überlegen, wie ich die verschiedenen Aspekte abdecken kann. Mir gehen noch ein paar Fragen durch den Kopf:
Sollen "deprecated" Module nicht mehr installiert werden? Oder nicht mehr abgedated? Oder soll ein Nachfolgemodul nicht installiert werden, solange die deprecated Module noch installiert sind?
Bei den Favicon-Module könnte man es auch dem User überlassen, je nachdem welche Module er aktiviert/deaktiviert ergibt sich ein anderes Ergebnis
Sollen Module wie Topola ganz aus der Liste genommen werden? Oder eine Warnung vor der Installation angezeigt werden?
Noch eine Anmerkung: Ich blende in meinen Modulen bei solchen Themen eine rote Warnmeldung in den Module Settings ein, in der Hoffnung, dass der Admin hier auch einmal vorbeikommt.
Sollen "deprecated" Module nicht mehr installiert werden? Oder nicht mehr abgedated? -> doch der Nutzer kann Gründe haben, warum er beim alten Modul bleiben möchte.
Oder soll ein Nachfolgemodul nicht installiert werden, solange die deprecated Module noch installiert sind? -> Ja, so sehe ich das bei meinem hh-historic-events und beim mtv_Nachfolge-Modul. Hier ist eine Nutzerinteraktion nötig: "Soll ich die alten Module x, y deaktivieren, damit Du das Nachfolgemodul z installieren kannst?"
Bei den Favicon-Module könnte man es auch dem User überlassen, je nachdem welche Module er aktiviert/deaktiviert ergibt sich ein anderes Ergebnis -> ja das ist kein Fall "Nachfolge" sondern der Fall "Alternative". Hier bietet sich an den Nutzer darauf hinzuweisen, dass er von den Modulen x, y und z nur eines aktivieren sollte.
Du hast ja ein paar Ausschlusskriterien, welche Module Du nicht in Deine Liste aufnimmst. Ich würde das so belassen, also Topola nicht zur Installation anbieten (wg. schwerwiegendem Sicherheitsproblem). Ähnliches gilt für Module, die in einem frühen Alpha/Beta-Stand sind oder bei/nach der Installation zu Fehlern führen oder das Patchen des webtrees-Kerns erfordern.
Eine rote Warnmeldung habe ich noch nie gesehen. Ich werde darauf achten. Meinst Du ich sollte das veraltete Modul hh_wars_battles extra noch einmal mit einem Release versehen nur um dort eine Warnung einzubauen "dieses Modul ist veraltet, nutze das neue Modul hh-historic-events"?
Meinst Du ich sollte das veraltete Modul hh_wars_battles extra noch einmal mit einem Release versehen nur um dort eine Warnung einzubauen "dieses Modul ist veraltet, nutze das neue Modul hh-historic-events"?
Ich würde es eher umgekehrt vorschlagen: Wenn man die Settings vom neuen Modul öffnet, sollte dort (ggfs. mit roter Warnmeldung) angezeigt werden, dass das veraltete Modul deinstalliert werden soll.
Du hast ja ein paar Ausschlusskriterien, welche Module Du nicht in Deine Liste aufnimmst. Ich würde das so belassen, also Topola nicht zur Installation anbieten (wg. schwerwiegendem Sicherheitsproblem). Ähnliches gilt für Module, die in einem frühen Alpha/Beta-Stand sind oder bei/nach der Installation zu Fehlern führen oder das Patchen des webtrees-Kerns erfordern.
Ich bin immer noch auf der Suche nach dem Feinschliff für die Strategie zur Aufnahme in CMM. Im Prinzip folge ich der Logik, die Du hier vorschlägst. Dabei versuche ich auch mit Deiner Liste im Webtrees-Handbuch möglichst auf dem gleichen Stand zu bleiben.
Bzgl. Topola habe ich auch schon überlegt. Soll ich das komplett rausnehmen? Oder eine Warnung anzeigen?
Bei Beta-Versionen habe ich noch keine konsistente Logik. Ursprünglich wollte ich beta-Versionen eigentlich nicht anbieten. Andererseits fällt es mir schwer, eine Bewertung vorzunehmen und eigentlich sollen beta-Versionen ja von Usern getestet werden. Daher nehme ich beta-Versionen jetzt doch wieder auf, solange sie sich installieren lassen und keine direkten Fehler verursachen. Wenn der Autor die Version in GitHub als "Pre-Release" markiert nehme ich diese Version nicht auf, weil das GitHub-API diese Versionen nicht zurückgibt. Und ich möchte für Pre-Releases keine Extra-Konfigurationen erstellen.
Activity
Jefferson49 commentedon Jun 18, 2026
o.k., generell macht das für mich Sinn. Ich muss mir aber erst einmal überlegen, wie ich die verschiedenen Aspekte abdecken kann. Mir gehen noch ein paar Fragen durch den Kopf:
Noch eine Anmerkung: Ich blende in meinen Modulen bei solchen Themen eine rote Warnmeldung in den Module Settings ein, in der Hoffnung, dass der Admin hier auch einmal vorbeikommt.
hartenthaler commentedon Jun 18, 2026
Eine rote Warnmeldung habe ich noch nie gesehen. Ich werde darauf achten. Meinst Du ich sollte das veraltete Modul hh_wars_battles extra noch einmal mit einem Release versehen nur um dort eine Warnung einzubauen "dieses Modul ist veraltet, nutze das neue Modul hh-historic-events"?
Jefferson49 commentedon Jul 3, 2026
Ich würde es eher umgekehrt vorschlagen: Wenn man die Settings vom neuen Modul öffnet, sollte dort (ggfs. mit roter Warnmeldung) angezeigt werden, dass das veraltete Modul deinstalliert werden soll.
Jefferson49 commentedon Jul 3, 2026
Hier ein Beispiel aus einem anderen Modul von mir für einen ähnlich gelagerten Fall:
Jefferson49 commentedon Jul 3, 2026
Ich bin immer noch auf der Suche nach dem Feinschliff für die Strategie zur Aufnahme in CMM. Im Prinzip folge ich der Logik, die Du hier vorschlägst. Dabei versuche ich auch mit Deiner Liste im Webtrees-Handbuch möglichst auf dem gleichen Stand zu bleiben.
Bzgl. Topola habe ich auch schon überlegt. Soll ich das komplett rausnehmen? Oder eine Warnung anzeigen?
Bei Beta-Versionen habe ich noch keine konsistente Logik. Ursprünglich wollte ich beta-Versionen eigentlich nicht anbieten. Andererseits fällt es mir schwer, eine Bewertung vorzunehmen und eigentlich sollen beta-Versionen ja von Usern getestet werden. Daher nehme ich beta-Versionen jetzt doch wieder auf, solange sie sich installieren lassen und keine direkten Fehler verursachen. Wenn der Autor die Version in GitHub als "Pre-Release" markiert nehme ich diese Version nicht auf, weil das GitHub-API diese Versionen nicht zurückgibt. Und ich möchte für Pre-Releases keine Extra-Konfigurationen erstellen.