Meiner Meinung nach würde das Tag Customization > Theme component als Unterkategorie seinem Zweck besser dienen. Zumindest für mich sind sie im Vergleich zu Tags leichter zu finden, und in den letzten Jahren sind Theme Components im Vergleich zu ihren Plugin-Gegenstücken immer bedeutender geworden (viele davon werden in Theme Components umgewandelt, um die Nutzung zu erleichtern). Wenn man keinen besseren Begriff findet, verdienen sie… „gleiche“ Aufmerksamkeit. Immerhin sind sie extrem beliebt und sind heutzutage ein fester Bestandteil von Discourse.
Ich hoffe, Sie nehmen dies in Betracht. Ich bin kein Muttersprachler, also entschuldigen Sie bitte meine mangelnde Ausdrucksweise.
Im Interesse der Einfachheit würde ich mich fragen, ob es sinnvoll wäre, einen Schritt weiter zu gehen und die Kategorie als customize zu bezeichnen und diese vier Tags zu verwenden.
Ich stimme zu, dass Theme Components heutzutage für die meisten Discourse-Sites etwas wertvoller sind.
Ich denke, diese Formulierung wird zu Verwirrung führen. Admin → Anpassen gilt nur für Themes und Theme-Komponenten. Customization > Theme umfasst alles, was über diese Benutzeroberfläche in eine Site eingeführt werden kann.
Wir sehen bereits gelegentlich Probleme, wenn Benutzer Themes in ihre YML-Dateien einfügen und versuchen, Git-Repositories für Plugins über die Benutzeroberfläche hinzuzufügen. Die Beseitigung dieser Abgrenzung macht solche Fehler nur wahrscheinlicher.
Plugins sollten wirklich in ihrer eigenen Kategorie bleiben, oder?
Der Unterschied zwischen einer Theme-Komponente und einem Plugin ist in meinem Kopf bereits unschärfer geworden. Alles, was wir tun können, um es den Nutzern zu erleichtern, die beiden zu unterscheiden, wird auf lange Sicht viel bewirken, bin ich mir sicher.
Das ist irgendwie witzig: Lange Zeit hatten WordPress-Entwickler die Frage, wo sie Funktionalität einbetten sollten, und es gab Debatten darüber, wie viel Code in ein “Theme” und wie viel in ein “Plugin” gehört. Diese Debatte wirkt heute fast schon uralt, da alles und jedes ein JS-Block ist. Aber aufgrund der Beziehung zur Kernsoftware müssen wir immer noch herausfinden, wo Code hingehört – in ein “Plugin” oder ein “Block-Muster”.
Ich hatte bei Plugins in Discourse noch nie ein solches Gefühl, hauptsächlich weil die Nutzer im Laufe der Jahre einige brillante Theme-Komponenten-Hacks entwickelt haben. Wenn mich jemand fragen würde, was der Unterschied zwischen “Plugins” und “Theme-Komponenten” ist, wäre mein erster Gedanke: Das eine benötigt ein URL-Feld zur Installation, das andere erfordert einen Neuaufbau der Site.
Und das wird er auch sein, denn der Unterschied basiert darauf, wie man etwas installiert. Nicht auf dem Zweck. Das ist eine entwicklerhafte Art, die Welt um sich herum zu sehen
Nur eine Anmerkung zum Tagging: Es scheint einfacher zu sein, zu vergessen, ein Thema zu taggen, als zu vergessen, die Kategorie auszuwählen. Es gibt bereits einige Themen ohne Tags.
Ich bin auf jeden Fall dafür, die Kategorien und Tags einer Gesundheitsprüfung zu unterziehen. Es gab in letzter Zeit ein paar gute Vorschläge, die Struktur etwas zu verändern, daher werde ich all das zusammenfassen und sehen, wohin wir kommen. Ich denke, alles, was Meta für neue oder gelegentliche Benutzer intuitiver macht, kann nur von Vorteil sein.
Das sollte jetzt weniger ein Problem sein, da es einen dedizierten Community-Moderator gibt. () Ich denke, wenn ich das Ganze sortiere und organisiere, während ich es tue, sollte das viel abdecken. Und wir haben eine gute Anzahl von TL3s und TL4s, also wird die Verstärkung eines konsistenten Musters es anderen Leuten hoffentlich leichter machen, sich ebenfalls zu beteiligen.
Ich betrachte es immer noch als Frontend- versus Backend-Änderungen, aber das Upgrade auf Ember hat verschwimmen lassen, was das für mich jetzt bedeutet. Es scheint, dass es in einem Theme/einer Theme-Komponente so viel mehr Möglichkeiten gibt als zuvor (was großartig ist, wenn man gehostet wird und keinen einfachen Zugang zum Hinzufügen eines Plugins hat ).
Ich denke, das ist eine ziemlich nützliche Unterscheidung für Nicht-Entwickler. Rot = /admin/customize, Gelb = app.yml. Ich denke, das ist wahrscheinlich alles, was man als Administrator wissen muss, wenn man eine bestehende Anpassung installiert, anstatt als Entwickler, der eine neue erstellen möchte.
Danke für den Vorschlag @Decorbuz Ich werde einige Ideen zusammenstellen und sehen, was wir tun können.
Gleiche Frage wie bei Smartphones: Sind sie Computer oder nicht? Die Grenzen sind nicht mehr so scharf.
Deshalb muss jedes Forum eine logische Wahl treffen, wie es Dinge anordnet: Entweder nach Idee oder Nutzung (UX und Zielgruppe sind wichtig) oder sind technische Lösungen wichtiger (Entwickler-/Codebasis-Denken).
Es gibt keine richtigen oder falschen Lösungen, solange die Benutzer finden, wonach sie suchen.
Nun, es gibt ab und zu falsche Lösungen. Gesunde Plugins/Themes/Komponenten mit kaputten zu vermischen, sodass man das richtige Tag finden muss, ist wirklich, wirklich schlechte Idee
Und im Allgemeinen gibt es einen weiteren Fehler, den Admins oft machen und wovor sogar Tag-Docs oder ähnliches von Meta warnen, wenn ich mich richtig erinnere: Eine Kategorie generiert keine Inhalte, aber leere oder wenig besuchte machen die Dinge nur unübersichtlich.
Ein Mangel an Klarheit bedeutet nicht automatisch, dass sie zusammengeführt werden müssen, insbesondere unter dem von Justin oben vorgeschlagenen Namen. Wir könnten stattdessen auch bessere Erklärungen zu jeder Kategorie hinzufügen und auf diese Weise einige der Mehrdeutigkeiten beseitigen.
#customization:plugin-Themen erfordern einen Neuaufbau und können nur von Benutzern mit Root-Zugriff durchgeführt werden. Es handelt sich um Änderungen mit höherem Risiko, die die Verfügbarkeit der Website beeinflussen.
Ich denke auch so darüber. Wenn es eine Änderung im Backend (Ruby-Code) erfordert, sei es das Speichern von etwas in der Datenbank oder das Ändern des API-Verhaltens, benötigen Sie höchstwahrscheinlich ein Plugin.
Wenn die Änderung nur die Benutzeroberfläche betrifft, ist es besser, mit einer Theme-Komponente zu beginnen und später auf ein Plugin zurückzugreifen, wenn die Dinge eskalieren, komplizierter werden und sich herausstellt, dass Änderungen im Backend notwendig sind.
Diese Idee gefällt mir. Es ist etwas umständlicher als eine einzelne Kategorie mit verschiedenen Tags, aber ich mag eine stärkere Abgrenzung zwischen diesen verschiedenen Anpassungselementen.
Ein Theme kann sich nur um das Aussehen drehen, während ein Plugin Zugriff auf das Betriebssystem des Computers benötigt, um es zu installieren. Es sind sehr unterschiedliche Dinge und richtige Kategorien ermöglichen es beispielsweise dem ersten Thema in der Kategorie, neuen Benutzern den Kontext über die Unterschiede zwischen ihnen zu vermitteln. Wie man installiert, Entwicklerdokumentation usw.
Alles, was wir tun können, um es den Nutzern zu erleichtern, die beiden zu unterscheiden, wird auf lange Sicht viel bewirken, bin ich mir sicher.
Ich denke, alles, was Meta für neue oder gelegentliche Benutzer intuitiver macht, kann nur von Vorteil sein.
