Skip to content

Manage depreciated modules #63

Open

Description

@hartenthaler

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.

Activity

  1. Jefferson49 commented on Jun 18, 2026

    @Jefferson49
    Owner

    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.

  2. hartenthaler commented on Jun 18, 2026

    @hartenthaler
    Author
    • 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"?

  3. Jefferson49 commented on Jul 3, 2026

    @Jefferson49
    Owner

    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.

  4. Jefferson49 commented on Jul 3, 2026

    @Jefferson49
    Owner

    Eine rote Warnmeldung habe ich noch nie gesehen. Ich werde darauf achten.

    Hier ein Beispiel aus einem anderen Modul von mir für einen ähnlich gelagerten Fall:

    Image
  5. Jefferson49 commented on Jul 3, 2026

    @Jefferson49
    Owner

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions