Ok, ho appena spinto un aggiornamento che dovrebbe risolvere il problema con le icone che non funzionavano. Le ho verificate specificamente su tutte e tre le icone e ora funzionano. Mentre esaminavo il codice, ho anche reso i nomi dei badge insensibili alle maiuscole/minuscole.
Il supporto per le localizzazioni sarà la priorità numero 1 la prossima volta che avrò l’opportunità di occuparmene.
Per me è stato molto confuso, perché sembrava stesse cercando nell’elenco dei badge del sito e non li trovasse. Ho provato un aggiornamento forzato per far sì che venissero trovati i miei nuovi badge, ecc. Sono contento che funzioni, ma forse l’interfaccia potrebbe essere modificata per trasformarla in una semplice casella di testo, invece di eseguire quella ricerca non funzionale? Credo che questo renderebbe l’uso meno confuso.
È normale ricevere il messaggio “Le modifiche locali verranno cancellate dall’aggiornamento. Sei sicuro di voler continuare?” quando si aggiorna un componente del tema? Sono quasi certo al 99,9% di non aver apportato modifiche e le informazioni del commit di git sembrano relative all’aggiornamento, non a modifiche locali:
diff --git a/discourse-post-badges/about.json b/discourse-post-badges/about.json
new file mode 100644
index 0000000..eb86c4b
--- /dev/null
+++ b/discourse-post-badges/about.json
@@ -0,0 +1,15 @@
+{
+ "name": "Post Badges",
+ "component": true,
+ "license_url": "https://github.com/tshenry/discourse-post-badges/blob/master/LICENSE",
+ "about_url": "https://meta.discourse.org/t/post-badges-component/114722",
+ "authors": null,
+ "theme_version": null,
+ "minimum_discourse_version": null,
+ "maximum_discourse_version": null,
+ "assets": {
+ },
+ "color_schemes": {
+ },
+ "learn_more": "https://meta.discourse.org/t/beginners-guide-to-using-discourse-themes/91966"
+}
\ No newline at end of file
diff --git a/common/common.scss b/discourse-post-badges/common/common.scss
similarity index 100%
rename from common/common.scss
rename to discourse-post-badges/common/common.scss
diff --git a/common/head_tag.html b/discourse-post-badges/common/head_tag.html
similarity index 100%
rename from common/head_tag.html
rename to discourse-post-badges/common/head_tag.html
diff --git a/discourse-post-badges/settings.yml b/discourse-post-badges/settings.yml
new file mode 100644
index 0000000..7e7e250
--- /dev/null
+++ b/discourse-post-badges/settings.yml
@@ -0,0 +1,21 @@
+badges:
+ type: list
+ default: ""
+ description:
+ en: 'Use the name of the badge as it appears on the
+ <a href="/admin/badges">list of badges</a>.
+ Post badges will appear in the order they are
+ added to this setting.'
+badge_link_destination:
+ type: enum
+ default: "user's badge page"
+ choices:
+ - "badge overview page"
+ description:
+ en: "Where a user will be taken when they click on a post badge."
+only_show_highest_trust_level:
+ type: bool
+ default: false
+ description:
+ en: "When including trust level badges (Basic, Member, Regular, Leader),
+ only show the highest trust level a user has earned."
Modificato per aggiungere: Ho eseguito l’aggiornamento e funziona correttamente. Quindi…
L’interfaccia utente delle impostazioni del tema è comune al core di Discourse, quindi non posso fare nulla per migliorare quella specifica impostazione all’interno del componente stesso. Sarebbe sicuramente auspicabile renderla un po’ più intuitiva o, forse, aggiungere in futuro la possibilità di popolare dinamicamente un elenco ricercabile.
So che questo codice andrà perso quando il componente verrà aggiornato, quindi mi chiedo se esista un modo migliore per farlo? Potrei, ad esempio, sovrascrivere la funzione buildBadge?
Informazioni di contesto: vogliamo mostrare questa icona solo per gli utenti che hanno effettivamente un portfolio, ovvero che hanno creato almeno un topic nella nostra categoria Artwork. Questo è facilmente realizzabile tramite una query per i badge e, dato che stiamo già utilizzando il componente Post Badges sul nostro sito, questa ci è sembrata un’approccio ragionevole.
Con il problema specifico della ricerca dei badge che non funziona, sì. Si tratta di un problema noto dell’interfaccia utente che ho menzionato poco fa, in uno dei post precedenti.
@bartv, mi piacerebbe sicuramente fare un passaggio di miglioramento/refactoring su questo componente nel prossimo futuro. Vedrò cosa posso fare per ristrutturare le cose in modo da permetterti di gestire le sovrascritture in un componente tema separato. Non sono sicuro di quando potrò occuparmene, ma aggiornerò sicuramente questo argomento non appena ci saranno novità.
Non al momento, ma terrò a mente questa possibilità la prossima volta che lavorerò sul componente.
Corretto, vedi:
Quando lavorerò all’aggiornamento di questo componente, vedrò se riesco a trovare una soluzione più elegante per questo problema.