Gibt es eine Möglichkeit, von einer Theme-Komponente auf die Einstellungen einer anderen Theme-Komponente zuzugreifen? Es scheint, dass settings nur die Einstellungen für die Theme-Komponente enthält, in der sie sich befindet.
Wenn es nicht möglich ist, von einer Theme-Komponente auf die Einstellungen einer anderen Theme-Komponente zuzugreifen, wie ist der beste Weg, dies zu tun?
eine einzige Theme-Komponente haben?
Einstellungen in das primäre Theme verschieben (aber sind diese verfügbar? Das habe ich noch nicht getestet).
[details=" Dies ist technisch machbar, aber wie David unten angegeben hat, verwenden Sie es bitte nicht "]Ich habe es mir angesehen, weil es eine ziemlich interessante Frage ist!
Es gibt eine Stelle in discourse/lib/theme-settings-store, an der die Theme-Einstellungen gespeichert sind und exportierte Funktionen wie getObjectForTheme oder getSetting verwendet werden können.
Sie können den Wert einer Einstellung für jede Theme-Komponente abrufen, solange Sie deren ID haben.
Ich konnte jedoch keine einfache Möglichkeit finden, die Zuordnung von Übersetzungs-ID zu Name abzurufen.
Das gesagt, Sie könnten den folgenden Trick anwenden:
// Ruft aus <link>-Tags die Theme-Name-zu-ID-Zuordnung für die aktiven Theme-Komponenten ab
const themesComponents = Array.from(
document.querySelectorAll("link[data-theme-name]")
).reduce((acc, link) => {
acc[link.dataset.themeName] = parseInt(link.dataset.themeId, 10);
return acc;
}, {});
// Ruft die Theme-ID basierend auf ihrem Komponentennamen ab
const themeId = themesComponents["discotoc"];
// Ruft alle Einstellungen ab
const themeSettings = getObjectForTheme(themeId);
// Ruft eine bestimmte Einstellung ab
const themeSetting = getSetting(themeId, "anchor_icon");
Einstellungen aus verschiedenen Themes/Theme-Komponenten sind bewusst isoliert. Abhängigkeiten zwischen Themes/Theme-Komponenten machen deren Entwicklung und Wartung sehr schwierig.
Wie @Arkshine gezeigt hat, ist es technisch möglich, sich den Weg zu den Daten zu “hacken”, aber ich würde DRINGEND davon abraten. Die Strategie wird fehlschlagen, wenn ein Administrator den Namen eines Themes im Admin-Panel ändert, und es ist auch sehr wahrscheinlich, dass sie bei zukünftigen Kernänderungen zufällig fehlschlägt.
Mein Fehler, mir ist bewusst geworden, dass der von mir bereitgestellte Code möglicherweise nicht zuverlässig ist. Ich sollte wirklich vorsichtig sein, was ich hier anzeige. Hacking macht Spaß, aber es dauert, bis es zu unerwünschter Nutzung und Problemen in der Zukunft führt.
Keine Sorge, @Arkshine – es ist immer gut, zu experimentieren. Der Hinweis [details] in deinem Beitrag ist gut, um sicherzustellen, dass die Leute die Risiken kennen, die sie eingehen
Wenn das Teilen von Einstellungen wie diesen zwischen Plugins und/oder Theme-Komponenten zu einer häufigen Anforderung wird, können wir sicherlich robustere Optionen ausarbeiten. Vielleicht können wir dieses Thema nutzen, um Anwendungsfälle darzulegen.
Mein Gefühl ist, dass, wenn ein Theme versucht, Einstellungen von einem anderen Theme zu verwenden, … vielleicht sollten sie in einem einzigen Repository zusammengeführt werden?
