RSS #2
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Bisogna discutere sul come generare il feed RSS e successivamente far puntare la pagina al suddetto feed
in questo momento abbiamo un file in /var/www/feed.xml che viene editato a mano
https://unit.abbiamoundominio.org/feed.xml
Vista la frequenza dei feed, (in tutto ne sono circa 8) si poteva fare.
Si è detto, quando metteremo pelican, fa lui i feed.
Mettiamo pelican?
Tenendo anche pagine statiche, magari, tipo pelican fa il b/log.
non volevo chiudere la issue
le pagine son poche quindi si dovrebbe fare in fretta a convertire da html a markdown,
per il resto il punto cruciale temo sia il tema, ne ho visti un po' e non me ne piace neanche uno,
alzi la mano chi ci piace lavorare sui temi o ha temi decenti da suggerire, almeno come punto di partenza :)
cmq creerei un repository website-pelican (e' un progetto proprio diverso, un branch non mi pare adatto) dove aggiungere le pagine e il tema.
se non ci sono contrarieta' creo il repository e ci metto la struttura base.
ma qualcuno di noi ha mai usato pelican ? potremmo anche fare una serata brainstorming di imparaggio collettivo.
Si, ci vuole un momento di imparaggio collettivo su pelican.
Mi sono trovato (su git il repo: minimo pelican theme) a ragionare se dividere la splash page ed eventuali altre pagine dal sito generato da pelican che vedo come un archivio bene organizzabile per data, categoria, tag, ma non altrettanto bene come homepage visto che per natura presenta in evidenza i nuovi contenuti, come un blog.
Si potrebbe provare a simulare il sito intero con pelican per scoprire cosa va bene e cosa no.
Dovremmo ragionare anche, oltre al tema da usare, su come inserire i contenuti. Presumo via git-push, la preview di minimo: unit.abbiamoundominio.org/minimo è stata generata con un rsync via ssh e la cosa forse non è adatta a una multiutenza.
questo e' un sito statico in pelican in cui non c'e' la parte "blog":
https://mcss.mosra.cz/
mi pare basti spostare gli "articles" in una cartella separata e usare la cartella principale per le "pages".
ha anche delle dettagliate spiegazioni per il css per chi ama il genere.
(nota: non e' fatto in Markdown ma in RestructuredText, che e' un formato un po' piu' strutturato).
su come distribuire il sito, non mi pare che gitea supporti nativamente qualche forma di CI (continuous integretation), e non starei ad installarne una per quel poco che ci serve, quindi bho:
uno script su zaphoda che faccia git pull da qualche parte, make del sito e poi rsync della cartella output nel posto giusto ? c'e' pero' da loggarsi su zaphoda per lanciarlo.
uno script locale che faccia rsync su ssh, magari lanciato in automatico da un git hook post-commit (lo script deve essere condiviso, potrebbe stare in git assieme al sito)
ma come funziona con i permessi ?
oppure indagare cosa e' possibile fare usando i git hooks "remoti",
ad es. vedi https://gist.github.com/noelboss/3fe13927025b89757f8fb12e9066f2fa
una volta fatto il setup e' sicuramente piu' comodo, pero' mi pare richieda un setup
che non e' proprio immediato.
in alternativa un playbook ansible (abbiamo gia' un repository di playbooks ansible, ma richiede di installarsi ansible, e il repository dei playbooks), insomma anche qui' si richiede un setup minimo ma una volta fatto rende il tutto abbastanza semplice.
l'uno non esclude l'altro, i primi due mi paiono la scelta piu' semplice
Ìl nostro CSS al momento è abbastanza semplice, potremmo scriverci un nostro tema in modo relativamente semplice. (Non ho ancora avuto modo di vedere quello di dan)
Per la parte di deploy: KISS. (Finché non si scala/l'operazione diventa fastidiosa). Uno scriptino sul repo per iniziare non è una pessima idea.
Su ReStructuredText: Odio molte cose di markdown (la specifica richiede spazi (carattereri invisibili) alla fine di una riga semplicemente per fare un break line, etc.) quindi decisi di provare RST per scrivere un piccolo documento con Pandoc e compangnia bella). Alla fine sono tornato al Markdown (non-standard) di Pandoc. Nonostante la sintassi sia più sana, ha limitazioni non indifferenti, per esempio: niente testo bold e italic.
Se proprio non volessimo usare Markdown, proverei AsciiDoc (che non credo sia supportato da Pandoc, ma ha un proprio compilatore) https://github.com/jgm/pandoc/issues/1456
markdown va bene, ieri sera ho "tradotto" tutte le pagine del sito in markdown,
sul tema invece mi sono un po' bloccato a fare alcune prove,
lo trovo (cosi' come avevo gia' visto con hugo) un aspetto "gestito" male, dal software, ma tant'e', forse e' solo ignoranza mia.
Ho fatto una prova di generazione su zaphoda con il tema minimo, il tema fa sempre pena, ma ha funzionato.
su zaphoda:
per evitare l'errore:
WARNING: Locale could not be set. Check the LOCALE setting, ensuring it is valid and available on your system.
sudo dpkg-reconfigure locales
aggiunto
it_IT.UTF-8
, perché è definita nel pelicanconf.pyedit publishconf.py
da:
SITEURL = 'https://unit.abbiamoundominio.org/minimo'
a:
SITEURL = 'https://unit.abbiamoundominio.org/minimo2'
https://unit.abbiamoundominio.org/minimo2/
allora, anche io ho fatto un po' di progressi, convertendo i contenuti attuali,
il risultato sta in https://unit.abbiamoundominio.org/tmp/
ho creato un repository apposito per il sito in pelican:
https://git.abbiamoundominio.org/unit/website-pelican
ci sono un tot di cose da dire ma essendo parecchie per ora le ho messe dentro il file LEGGIMI.md di quel repository.
leggete, valutate, commentate, tenendo conto che ad es. il tema lo si cambia/sistema
quando si vuole, l'importante e' che ad esempio conveniamo sugli aspetti piu' strutturali (dove sono i files, come vengono chiamati etc.).
Per me entro la ricorrenza della morte di cristo dovremmo riuscire a mandarlo in produzione.
Il repo del tema 'minimo' (se serve) è ora solo un theme. Senza conf, Makefile e contents.
Rimosse le dir minimo/ e minimo2/ dal sito.
Aggiunto al repo 'website-pelican' una hidden page 404 in /pages/404.md - Credo basti chiamarla in nginx conf:
error_page 404 /pages/404.html;
La struttura: pages, news, images, media è molto ok. (forse cambierei il nome della dir 'blog' con 'news' per fare match).
Alcune pagine non erano linkate in homepage e potrebbero essere aggiunte:
Come pure le immagini in media/ (per accompagnare il post relativo all'evento che apparve solo nella homepage e fu riscritto dall'evento successivo)
le immagini le ho aggiunte,
per le pagine: nosocial shutdown e letture sono piu' post da "blog",
nosocial potremmo semplicemente farlo diventare un post del blog retrodatato (un po'
come per il comunicato dello sgombero di macao), ma anche no, quel che
dovevamo dire sta in nolike.
per letture invece, quando il sito andra' in produzione si potra' fare un post sul blog
con una categoria "letture" nel caso volessimo riproporre quel contenuto.
io chiuderei comunque questa issue e nel caso riaprirei di la, nel repository website-pelican, se ci sono altri commenti.
Se non ci manca nulla potremmo mandare il sito in produzione e continuare gli aggiustamenti live.
I feed RSS manterranno lo stesso URL (fantastico che ci hai pensato).
Si, comunicati, nosocial-shutdown etc diventano post con datazione originale.
Direi di non cancellare, ma solo spostare l'intera dir /var/www/unit.abbiamoundominio.org. in modo da poter a posteriori ripescare eventuali cose dimenticate.
Agreement sul chiudere qui e continuare su website-pelican.