Meiner Meinung nach würde das Tag #theme-component besser als Unterkategorie dienen. Zumindest für mich sind sie leichter zu finden als Tags, und in den letzten Jahren sind Theme-Komponenten im Vergleich zu ihren #plugin-Gegenstücken immer wichtiger geworden (viele davon werden in Theme-Komponenten umgewandelt, um die Nutzung zu erleichtern). Mangels eines besseren Begriffs verdienen sie… eine „gleichwertige“ Behandlung. Schließlich sind sie äußerst beliebt und ein fester Bestandteil von Discourse heutzutage.
Ich hoffe, Sie berücksichtigen dies. Ich bin kein Muttersprachler, also entschuldigen Sie 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 glaube, dass diese Sprache zu Verwirrung führen wird. Admin->Anpassen ist nur für Themes und Theme-Komponenten. Theme enthält alles, was über diese Benutzeroberfläche auf eine Website eingeführt werden kann.
Wir sehen bereits gelegentlich Probleme mit Benutzern, die Themes in ihre YML einfügen und versuchen, Git-Repositories für Plugins über die Benutzeroberfläche hinzuzufügen. Die Eliminierung der Abgrenzung macht diese Fehler nur wahrscheinlicher.
Plugins müssen wirklich in ihrer eigenen Kategorie bleiben, oder?
Der Unterschied zwischen einer Theme-Komponente und einem Plugin ist in meinem Kopf bereits verschwommen. Alles, was wir tun können, um es den Leuten leichter zu machen, zu wissen, was was ist, wird sicher viel bewirken.
Das ist irgendwie lustig, denn lange Zeit mussten WordPress-Entwickler entscheiden, wo sie Funktionalität einbauen sollten, und es gab Debatten darüber, wie viel Code zu einem „Theme“ und wie viel zu einem „Plugin“ gehört. Diese Debatte ist heute fast antiquiert, wo alles und jedes ein JS-Block ist, aber aufgrund seiner Beziehung zur Kernsoftware müssen wir immer noch herausfinden, wo der Code hingehört, in einem „Plugin“ oder einem „Block-Muster“.
Ich hatte bei Plugins in Discourse nie ein solches Gefühl, hauptsächlich weil die Leute 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ürde ich zuerst denken: Eines benötigt ein URL-Feld zur Installation und das andere erfordert einen Neuaufbau der Website.
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.
Unklarheit bedeutet nicht automatisch, dass sie zusammengeführt werden müssen, insbesondere unter dem Namen, den Justin oben vorgeschlagen hat. Wir könnten auch bessere Erklärungen zu jeder Kategorie hinzufügen und auf diese Weise einige der Mehrdeutigkeiten beseitigen.
Theme und Theme component umschließen die vorgefertigten Anpassungen, die zur Laufzeit vorgenommen werden können.
#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 beeinträchtigen.
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 Leuten leichter zu machen, zu wissen, was was ist, wird sicher viel bewirken.
Ich denke, alles, was Meta für neue oder gelegentliche Benutzer intuitiver macht, kann nur von Vorteil sein.
