Forse questo può essere risolto con il CSS. Non compare mai, o puoi scorrere verso l’alto per vederlo? Quale browser e sistema operativo stai utilizzando? Forse possiamo renderlo fisso, ma in alto. Il problema è che alcuni browser hanno recentemente cercato di essere “creativi” e hanno spostato la barra del browser in basso.
I browser sono Firefox e Chrome su Android, su un telefono Motorola. La stessa cosa succede con l’app di Discourse.
La barra dei pulsanti è sempre presente, ma si trova sotto un menu a comparsa quando la selezione è nelle prime 3 righe visibili nella casella di testo.
Un’alternativa è inserire 3 ritorni a capo (CR/LF) prima del primo testo. Quindi eliminare questi extra prima di pubblicare.
Sì, l’ho appena testato. Capisco cosa intendi. È davvero fastidioso. Ma penso che le barre in basso siano ancora peggiori. Inoltre, devo fare ricerche su come farlo e non vengo pagato per questo. Probabilmente esiste un modo più pulito per farlo. Scommetto che altri progetti hanno lo stesso problema e che esiste una soluzione standardizzata. Ma come ho detto, ho altre priorità. Scusa per la franchezza ![]()
EDIT: solo una nota. C’è un modo per disabilitare il clic destro (doppio clic su mobile). https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript ma così gli utenti non possono copiare. È un disastro…
La soluzione alternativa è fattibile, solo scomoda.
Probabilmente esiste un approccio CSS per mobile per questo fastidio. Dovrò solo cercarlo.
Aggiungere molto codice per questo caso particolare non sarebbe un buon utilizzo del tuo tempo e della tua attenzione. (Inoltre aggiunge sovraccarico.) Grazie per aver condiviso i tuoi progetti con la comunità. È stato molto generoso da parte tua.
Ok, grazie mille per la segnalazione. L’ho appena corretto
Un consiglio: Rails aggiunge il metodo .present? in alcune classi Ruby, che è preferibile al confronto con stringhe vuote. Funziona principalmente con array e stringhe.
Esiste anche .empty?, che è l’opposto di .present?.
Ho rimosso intenzionalmente questo pulsante perché le immagini devono essere caricate tramite l’editor. Tuttavia, ho appena scoperto che il menu di selezione dei file non si apre su Android Firefox per qualche motivo. Per indagare, devo installare il debug remoto, quindi ci vorrà del tempo per risolvere il problema. Fino ad allora, usate semplicemente l’editor avanzato per caricare le immagini.
AGGIORNAMENTO: in realtà funziona perfettamente. Non si apriva semplicemente perché avevo precedentemente negato all’app l’accesso alla fotocamera. Quindi potete usare lo stesso pulsante di caricamento immagini che usereste su desktop. Se siete confusi, guardate lo screenshot che ho caricato per testarlo:
https://cidian.social/t/file-upload-from-mobile/292
Voglio abilitare solo le opzioni Grassetto, Corsivo, Collegamento e Caricamento immagine nella barra degli strumenti. Come posso farlo?
Aggiungerò un’opzione per configurarlo una volta completato.
Significa che non esiste una soluzione alternativa per questo? Non posso modificare il file di configurazione di CKEditor che è stato utilizzato all’interno del plugin?
Lo renderai compatibile con altri plugin come ad esempio Image Annotation, BB markup, ecc.?
Ok, lasciatemi chiarire una cosa: quando parlo di “cose che non funzionano”, intendo semplicemente che non vengono visualizzate nella finestra di input WYSIWYG. Tutto funziona correttamente nel post finale. Questo editor è solo un modo diverso per creare markdown al momento. Alla fine esce sempre markdown. Dal mio punto di vista, l’approccio “solo HTML” è la strada da seguire in futuro. Markdown, BBCode e simili sono cose del passato che offrono un’esperienza utente eccessivamente complessa. Ma ovviamente non implementerò ogni singola funzionalità di BBCode o plugin personalizzato, perché non ne traggo alcun vantaggio. La mia priorità è il mio caso d’uso. Tuttavia, tengo anche a semplificare l’esperienza utente di Discourse per gli altri. Se vi piacciono markdown, BBCode e tutti questi “tag” nel vostro editor, forse questa non è la soluzione giusta per voi.
Vorrei anche che questa discussione diventasse più costruttiva. Sarei felice di conoscere i casi d’uso e le ragioni per cui le persone desiderano utilizzare un editor WYSIWYG invece di quello attuale. Sono anche interessato a sapere quali vantaggi vi aspettate da questa soluzione e quali obiettivi volete raggiungere?
Forse questo può portarci da qualche parte. Chiedere “puoi fare tutte queste cose casuali? …(gratis)” non è utile.
Cordiali saluti,
Spirobel
Passare all’HTML e non supportare il Markdown renderà tutti i post creati in HTML non modificabili non appena il tuo plugin verrà disattivato. È corretto?
@spirobel anche se personalmente non uso il tuo plugin, ammiro le sue funzionalità e ti faccio i miei complimenti per il grande impegno!
Anche se concordo sul fatto che bbcode sia una sintassi obsoleta, l’idea che Markdown sia una cosa del passato è errata dal mio punto di vista – anzi, è esattamente il contrario: il set di funzionalità di base è destinato a rimanere per molto tempo.
Le due ragioni principali sono:
- Formattazione tramite digitazione: puoi formattare correttamente il testo semplicemente digitando, il che rende più facile concentrarsi e scrivere in modo produttivo.
- Leggibile anche senza rendering: la sintassi base di Markdown è istintivamente leggibile come testo grezzo, il che è molto utile per molti motivi.
È quando si cercano di estendere le funzionalità di Markdown (immagini, tabelle, ecc.) che, a mio avviso, tende a mostrare limiti e talvolta a rompersi a causa di una sintassi illeggibile e scomoda da digitare.
Secondo me, i migliori editor offrono una soluzione ibrida:
- La formattazione con sintassi di base viene visualizzata in linea, mantenendo comunque visibili i caratteri della sintassi in modalità modifica.
- Le funzionalità estese (immagini, tabelle, ecc.) dovrebbero ovviamente essere visualizzate anche in modalità modifica e, forse, non dovrebbero essere rappresentate dai caratteri della sintassi effettivi sullo schermo. Forse, oserei dire, dovrebbero essere considerati come plugin e memorizzati in un formato più adatto al tipo di dati.
Grazie mille per il tuo commento!
Capisco cosa intendi, ma sono ancora in disaccordo.
A lungo andare, gli utenti esperti sono meglio serviti dalle scorciatoie. Ad esempio, potrebbe esserci una scorciatoia per il corsivo, così da poterla premere mentre si continua a scrivere. La scorciatoia potrebbe anche essere qualcosa come CTRL+*, rendendola quasi simile all’uso del markdown.
Per quanto riguarda il punto 2, posso dire che anche l’HTML è leggibile, poiché viene sempre renderizzato (nel browser); se guardi un frammento di HTML in un editor di testo, puoi leggerlo. Va bene, il markdown potrebbe sembrare un po’ più elegante, ma solo se ti attieni a funzionalità molto basilari, e in quel caso non fa comunque alcuna differenza.
La soluzione ibrida, purtroppo, non è fattibile. Uno dei motivi per cui ho abbracciato l’idea di usare solo l’HTML è che mi permette di concentrarmi sulla creazione di un’interfaccia utente invece di dover ottenere un dottorato in linguistica informatica mentre debuggo errori nei parser linguistici. L’idea è ridurre il debito tecnico, non aumentarlo.
Alla fine, capisco molto bene da dove provieni. Ho letto anch’io la documentazione sul markdown. Ma per me, il paradigma dell’HTML solo è più convincente per ciò che sto per fare. Mi rendo anche conto che non ha senso convincere chi ama davvero il markdown: dovrebbero rimanere con l’editor così com’è ora. Ma credo che ci sia un altro gruppo di persone che potrebbe essere interessato a intraprendere una strada diversa. Questo plugin è anche molto più di un semplice editor WYSIWYG. Ho questa visione di utilizzare Discourse per costruire software che permetta alle persone di modificare collettivamente dati strutturati senza dover imparare un linguaggio di markup. Se guardi a grandi progetti come Wikipedia o Wikizionario e a tutte le formalità coinvolte nel contribuire a questi, vedo un potenziale sprecato. Voglio cambiare questo. E se voglio cambiare, devo prendere le funzionalità collaborative di Discourse e scartare il concetto di dover usare un linguaggio di markup per inserire dati nel sistema.
Capisco perché è stato utilizzato in Discourse in origine e le ragioni sono davvero valide. Ma i miei obiettivi sono diversi, quindi seguo anche un paradigma diverso.
Ottimo plugin, @spirobel! Questo è esattamente ciò di cui i nostri utenti poco esperti di tecnologia hanno bisogno e credo che darà una spinta notevole al funzionamento del nostro sito. Grazie per il tempo e lo sforzo che ci hai dedicato. Ho notato un paio di problemi che potrebbero essere utili
Conflitto con Shared Edits
Ho appena installato sia questo plugin che Discourse Shared Edits. Non sorprendentemente, entrano in conflitto un po’. Ma sembra che il problema possa essere risolto. Valuteresti di renderli compatibili? Personalmente, li considero entrambi indispensabili in futuro.
Ciò che accade è che quando modifico un post in condivisione usando l’Editor Base, il testo esistente nel post viene cancellato e può essere recuperato solo annullando la modifica.
@menzioni senza suggerimenti
L’Editor Base di Discourse sembra compromettere parzialmente la funzione @menzioni. Quando provo a menzionarti qui, ottengo questo:
Quando attivo l’Editor Base, i suggerimenti non appaiono più. Lo stesso accade se faccio clic su Modifica Avanzata.
Sì. Questo è ancora un lavoro in corso. Le menzioni sono nella mia lista. Non ho ancora esaminato la modifica condivisa, ma è certamente possibile implementarla. Tuttavia, è probabile che ciò non avverrà garantendo la compatibilità con il plugin per la modifica condivisa. Il cambiamento introdotto dall’editor di base è piuttosto significativo, quindi molto probabilmente sarà necessaria una soluzione all’interno dell’editor di base.
Hai parlato con @sam a riguardo? Potrebbe essere interessato alla possibilità e sicuramente darà consigli saggi.


