Preferisco il vecchio metodo per aggiungere allegati. Sarebbe fantastico se una qualsiasi impostazione di Discourse mi permettesse di scegliere lo schema.
Lo schema di sintassi è stato modificato di recente. Tuttavia, quello vecchio rimane valido. Suggerisco di dare all’amministratore la possibilità di scegliere quale sintassi (vecchia o nuova) fornire di default agli utenti.
Non mi piace il workaround con la barra verticale. Non è intuitivo ed è ancora in conflitto con le tabelle Markdown in generale.
Se pensate che non ci sia bisogno di una tale compatibilità con le versioni precedenti, allora dovreste almeno considerare l’implementazione di qualche meccanismo di completamento automatico per rilevare questo tipo di comportamento all’interno delle tabelle.
Non è in discussione offrire qualche tipo di impostazione o plugin che modifichi il modo in cui gli allegati sono specificati, passando da Markdown a HTML. Dovresti rivolgerti a Marketplace. Il vecchio formato crea numerosi problemi di portabilità con i file caricati.
Non sono contrario a risolvere in qualche modo questo caso particolare, ma è piuttosto difficile determinare se ci si trova all’interno di una tabella basandosi solo sulla posizione del cursore, quindi una soluzione automatica non è semplice da implementare.
Qual è stata l’intenzione di cambiare il formato senza fornire alcun task rake o qualcosa di simile? (Per aggiornare il vecchio codice…)
Ci sono stati diversi casi in cui il formato della sintassi è cambiato marginalmente, con un grande impatto sull’intero contenuto… ad esempio, con spazi mancanti tra gli hashtag delle sezioni e i loro nomi, o tra il simbolo > delle citazioni e il testo. Soprattutto su più livelli. È un disastro dover correggere manualmente questi cambiamenti per centinaia di post da parte di un solo amministratore. Credetemi. Mi sarebbe piaciuto essere consultato, in qualità di amministratore, se volevo seguire la vostra direzione o mantenere il formato sintattico attuale.
A mio parere, dovrebbe essere la priorità numero uno assicurarsi che ogni singola modifica al formato non comprometta l’usabilità delle funzionalità principali.
Non ho una conoscenza approfondita del problema relativo alla posizione del cursore. Vi credo. Ma dovrebbe essere possibile, dato che il compositore sembra sapere dove inizia e finisce una tabella. Finché siete in grado di determinare la posizione del cursore in qualsiasi punto all’interno, potreste aggiungere automaticamente una barra verticale per i caricamenti. Non è vero?
Esegui questo task solo se hai riscontrato problemi con i caricamenti in passato o se desideri migrare l’archiviazione da locale a S3.
Il 100% dei nostri siti ospitati utilizza inline, poiché ciò rende i caricamenti meno fragili.
Ritengo che ci sia un po’ di confusione su qualcosa che è essenzialmente un caso limite.
La stragrande maggioranza dei post esistenti contiene 0 tabelle. Dei rari post che effettivamente contengono tabelle, la maggior parte non include caricamenti.
Immagino potremmo supportare qualcosa del genere, invece della barra che è resistente alle tabelle:
Mi chiedo solo perché non riesco a cambiare il formato allo stile vecchio. La maggior parte degli allegati aggiunti in precedenza è ancora inclusa in questo modo e sembra che tutto funzioni perfettamente.
Gli aggiornamenti di Discourse rompono ripetutamente le funzionalità principali. E non c’è alcun ulteriore avviso sui conflitti.
Mi piace davvero molto lo sviluppo agile e il gestore di aggiornamenti Docker. Ma questo tipo di gestione delle versioni mi fa impazzire di nuovo e di nuovo.
C’è qualche possibilità che lo strumento di caricamento possa aggiungere automaticamente il carattere di escape quando carica un file che verrà utilizzato in una tabella? Mi ci sono voluti circa 20 minuti per capire cosa stesse causando il malfunzionamento della mia tabella e/o del caricamento in un articolo di tabella che avevamo.
Penso che un utente non tecnico si sarebbe semplicemente arreso.
Molto difficile da fare in modo accurato, il nostro motore markdown esegue solo il reverse mapping per riga, quindi avremmo bisogno di un po’ di logica speciale.
Se la PR per questo fosse abbastanza piccola, sarei comunque aperto a un miglioramento qui.