Meiner Meinung nach würde das Tag Customization > Theme component besser als Unterkategorie funktionieren. Zumindest für mich sind sie leichter zu finden als Tags, und in den letzten Jahren haben Theme-Komponenten im Vergleich zu ihren #customization:plugin-Pendants immer mehr an Bedeutung gewonnen (viele davon werden zur einfacheren Handhabung in Theme-Komponenten umgewandelt). Für Mangel an einem besseren Begriff verdienen sie eine „gleiche“ Behandlung. Immerhin sind sie extrem beliebt und stellen heutzutage einen festen Bestandteil von Discourse dar.
Ich hoffe, Sie berücksichtigen dies. Ich bin kein Muttersprachler, daher entschuldige ich mich für meine mangelnde Ausdrucksfähigkeit.
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 definitiv dafür, eine Gesundheitsprüfung der Kategorien und Tags durchzuführen. In letzter Zeit gab es einige gute Vorschläge, die Struktur ein wenig anzupassen, also werde ich all das zusammenfassen und sehen, wohin das führt. Ich denke, alles, was Meta für neue Benutzer oder Gelegenheitsnutzer intuitiver macht, kann nur positiv sein.
Das sollte jetzt weniger problematisch sein, da es einen dedizierten Community-Moderator gibt. () Ich denke, dass ich die Dinge sortiere und organisiere, während ich arbeite, sollte viel davon abdecken. Und wir haben eine ansehnliche Anzahl von TL3s und TL4s, also hoffe ich, dass die Verstärkung eines konsistenten Musters es auch anderen Leuten erleichtert, mitzumachen.
Ich denke immer noch an Frontend- versus Backend-Änderungen, aber das Upgrade auf Ember hat für mich auch die Bedeutung dessen verwischt. Es scheint, als wären damit so viel mehr Dinge in einem Theme oder Theme-Component möglich geworden als zuvor (was großartig ist, wenn Sie gehostet sind und keinen einfachen Zugang haben, um ein Plugin hinzuzufügen ).
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 Sie wirklich wissen müssen, wenn Sie ein Administrator sind, der eine vorhandene Anpassung installiert, und nicht ein 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.