Newsgroup: it.lavoro.professioni.webmaster
Titolo: blog statico: pro e contro?

trovandomi di fronte all'idea di progettare un blog stavo seriamente 
valutando un generatore statico tipo jekyll. il motivo pricipale è che 
vorrei dimenticarmi almeno in prima istanza dei problemi di sicurezza, 
plugin bucati, aggiornamenti dei medesimi e altre rogne del genere, 
concentrandomi su design e (ovviamente) contenuti.
 
al momento non riesco a vedere dei veri e propri "contro" rispetto a una 
soluzione wordpress. secondo voi mi sfugge qualcosa?

 soluzione wordpress. secondo voi mi sfugge qualcosa?
 
Secondo me la diffusione enorme dei vari CMS č solo abitudine/mancanza 
di conoscenza di alternative/poca dimestichezza con la riga di comando.
 
Forse l'unico impedimento serio che viene č la mancanza dei commenti in 
quest'epoca cosě "social", ci sono le soluzione terze tipo disqus 
oppure roba interna [1, 2] che aggiungono un minimo di dinamica al 
sito, ma niente di complesso o vulnerabile.
 
 
[1]: 
http://www.hezmatt.org/~mpalmer/blog/2011/07/19/static-comments-in-jekyll.html
 
 
[2]: 
http://theshed.hezmatt.org/jekyll-static-comments/
 
 
-- 
Andrea
 

 Un grandissimo vantaggio, IMHO.
 
Domanda da curioso: hai un sito su jekill?
 
Io ho visto i siti che citano come esempio, mi paiono tutti un po' 
poverini, ma dato che l'idea mi incuriosisce comincerò a studiarci 
sopra, a commenciare dalle tue segnalazioni sui gestori di commenti.
 

 Un grandissimo vantaggio, IMHO.
 
Ho cominciato a leggere qualcosa... Ma dove sta il vantaggio di passare 
da un programma in php a uno in ruby? (peraltro almeno uno dei plugin da 
te segnalati usa anche uno script php...). Forse nell'esigua lunghezza 
del codice e quindi nella più facile manutenzione e minore possibilità 
di bug / exploit?
E i provider? Il mio mi fornisce php, quanti forniscono ruby? Ce ne sono 
di economici?
 
 

 da un programma in php a uno in ruby? 
 
non passi da un programma php ad uno in ruby, passi da un programma php 
ad un sito *statico*.
jekyll è in ruby ma è il generatore, non serve lui le pagine. 
il vantaggio è proprio che hai un sito statico. quindi niente script lato 
server, niente di niente. 

rootkit wrote on 21/03/16 17:55:

Se è una cosa tua, che scrivi e gestisci tu, non vedo controindicazioni; a meno 
che non ti serva qualcosa di molto social come interattività nel qual caso non 
so quanto lavoro ti possa comportare in più.
 
Quando hai deciso, posta l'URL :-)
 
Gabriele

 Quando hai deciso, posta l'URL :-)
 
I miei tempi sono biblici, perché ho un lavoro, una famiglia (almeno per 
ora), e mille problemi con l'uno e con l'altra.
Casomai dovesse succedere te lo fornirò in privato.

 già pronti tra cui scegliere,
 
Mah, per il mio blog personale -che al momento non ho, per rispondere 
all'altra domanda- non è che mi interesserebbe molto.
Per la cronaca io ho dato un'occhiata a Hyde, perché sono più py-oriented.
 
-- 
Andrea
 

 pronti tra cui scegliere, tanto per dirne una.
 
a parte che si trovano anche template html, ma la cosa mi interessa 
relativamente. sul design vorrei lavorare personalmente e in questo caso 
essere vincolati al sistema di gestione temi wp mi è d'intralcio. 

 Per la cronaca io ho dato un'occhiata a Hyde, perché sono più py-oriented.
 
E questo che è fatto in JS invece?
http://www.metalsmith.io/
 
Solo che non capisco che tipo di JS, client-side o server-side?
Problemi di indicizzazione?
 


credo che tu faccia molta confusione.
quello è un generatore basato su node.js, quindi sì è scritto in 
javascript. ma il generatore, non il generato. il sito prodotto sono 
documenti statici che a gusto tuo possono o meno contenere javascript.

 di conoscenza di alternative/poca dimestichezza con la riga di comando.
 
Scusa... che centra la poca dimestichezza con la CLI e la diffusione dei 
CMS?
 
I CMS si sono diffusi perché sono più semplici da realizzare per il 
professionista e da gestire per il committente che può inserire 
autonomamente i contenuti.
 
E' vero ci sono anche molti improvvisati che fuori dalle 4 cosette non 
sanno fare... e sono quelli che non fanno la manutenzione annuale ai 
siti web.
 
Riguardo il problema sicurezza, l'unico che ho avuto in tanti anni è 
stato fatto sfruttando una falla presente nella versione del Plesk del 
provider che usavo all'epoca (e che non ha voluto ripristinare i 
backup). Tanto per capire... sono stati colpiti anche i siti statici 
realizzati con solo HTML.
 
Per il resto aggiorno tutti i siti man mano che escono dei nuovi 
aggiornamenti del core o delle estensioni di Joomla! o Wordpress. Certo 
è una lavoraccio se si hanno tanti siti da seguire ma non è gratuito per 
il cliente... c'è un costo annuale per la manutenzione. Se il cliente 
non la vuole pagare il sito non riceve la manutenzione.
 
 
-- 
Daniele Pinna
DAPINNA.COM
 
(leva oops per rispondere)
-----
Utente Skype: dapinna
DAPINNA.COM
        :  
http://www.dapinna.com
 
Il Docfa in Pillole:  
http://www.ildocfainpillole.it
 - Sito Aggiornato!!!
DAPINNA.COM
 su Facebook: 
https://www.facebook.com/dapinnadotcom
 
BLOG: 
http://storielaboratorioinformatica.wordpress.com
 

 Scusa... che centra la poca dimestichezza con la CLI e la diffusione dei CMS?
 
Non era riferito alla diffusione _in generale_ ma al contesto 
particolare del sito statico per un blog personale in cui le questioni 
cosmetiche sono pochissimo rilevanti, almeno per quanto mi riguarda.
 
_Immagino_ che in quel caso una persona che non è pratica della riga di 
comando preferisca istallare un wp qualsiasi e via.
 
Certo che è ancora più comodo usare una piattaforma come servizio e 
via, però c'è qualcosa che mi piace nel minimalismo del sito statico.
 
 
-- 
Andrea
 


 
Personalmente ho optato, dopo molta indecisione al momento di dover rifare da 
zero il mio sito principale che era html+css, per un sito statico che aggiorno 
"a mano"; però ho messo anche delle belle foto e effetti tipo "accordeon" per 
delle schede di prodotto :-)
Il motivo principale per cui sono rimasto in questo caso sull'html è la sicurezza.
Invece per creare dei siti dimostrativi di vario genere e farci varie prove ho 
scelto WordPress.
 
Quindi non è che una cosa escluda l'altra, dipende anche che pubblico devi 
raggiungere.
 
Gabriele
 

 effetti tipo "accordeon" per delle schede di prodotto :-)
 
Va benissimo la parte cosmetica se ti piace e/o serve, ma piuttosto che 
aggiornare a mano non č meglio un compilatore?
 
 
-- 
Andrea
 

 però c'è qualcosa che mi piace nel minimalismo del sito statico.
 
Certo... io ancora ho qualche cliente che ha un sito statico e lo tiene 
così perché non ha la necessità di aggiornare frequentemente il sito.


 innovativo o comunque d'impatto.
 
 
Cito le prime tre cose che mi vengono in mente:
* barra di ricerca (il sito statico deve reindirizzare su google?)
* nuvola dei tag
* calendario del blog
 
Sul mio personale le uso personalmente tutte e tre (soprattutto per 
rileggere cose vecchie che ancora mi interessano) anche se è un sito 
minimalistico.
 
La cosa è interessante, ma il generatore di siti statici non riesce a 
convincermi.
 

 Sul mio *sito* personale le uso personalmente tutte e tre (soprattutto per


 devi raggiungere.
 
Concordo.


 * calendario del blog
 
La quarta: elenco dei post attinenti (related post).
 

 minuti tra backup ed aggiornamenti :-)
 
Oppure usare appspot di google, dove se non mi sbaglio aggiorni in 
locale e poi sincronizzi sul cloud.
 


Non ho capito :-)
 
Non credo che il cloud di google (inteso come Google Drive... se parli 
di altro non so) si possa usare per un sito Web basato su PHP+DB


 di altro non so) si possa usare per un sito Web basato su PHP+DB
 
Secondo me parla di Google 	Cloud che si appoggia ad App Engine che mi 
pare supporti PHP nativamente già da un po' (prima si usava un 
interprete per la JVM).
 
 
-- 
Andrea
 


beh usando jekyll puoi pubblicare su github pages. 

 innovativo o comunque d'impatto.
 
beh a mio modo di vedere se vuoi un design spinto è molto più complicato 
realizzarlo con un cms piuttosto che con un motore di template statici. 
cioè i temi di wp sono comodi da utilizzare perché si installano e si 
cambiano in un attimo, ma personalizzarli magari con delle soluzioni un 
po' spinte non è cosa affatto banale.

 di altro non so) si possa usare per un sito Web basato su PHP+DB
 
https://googlecloudplatform.github.io/appengine-php-wordpress-starter-project/
 
 
Congratulations! You should now have a blog that loads rapidly, caches 
elegantly, sends email properly, and can support adding images and other 
media to blog posts! Most importantly, it will take advantage of 
Google's incredibly powerful infrastructure and scale gracefully to 
accomodate traffic that is hitting your blog.
 
Note: You'll want to keep that local copy of WordPress handy, because 
you'll need it to install custom themes and plugins. Because of the 
security sandbox, your live WordPress site can not write to the local 
files -- they're static. This means the auto-installation of themes and 
plugins in the WordPress dashboard will only work in the local WordPress 
that you run on your own machine. So, remember to do all your installing 
locally, then re-deploy your WordPress app.
 

 
https://googlecloudplatform.github.io/appengine-php-wordpress-starter-
 
project/
 
ecco, cadendo proprio a fagiuolo: questo sito è generato con jekyll e 
hostato da github :-)

 files -- they're static.
 
Notare però che questo è quello della discussione sono due significati 
diversi di statico.
Il sito web in questione è comunque dinamico nei contenuti ma statico 
"nel filesystem".
 
 
-- 
Andrea
 


 
Se devi fare da zero, allora usi un framework e crei quello che ti pare, oppure 
usi un tema che abbia molte libertà di modifica con un editor a moduli; io su 
questo mi trovo bene con quelli di Themify.
 
Gabriele


 
Ho sempre usato degli editor che mi permettessero di inserire codice manualmente.
Sono su Mac e al momento sto usando Flux che tra i tanti che ho provato è 
l'unico che gestisce decentemente pezzi di codice da includere (per tanti anni 
ho usato PageSpinner che però non veniva più aggiornato); nel senso che ad es. 
se modifico la parte che gestisce il menù lo faccio su una sola pagina e 
l'editor poi aggiorna tutto il sito.
Oppure tutta la parte di header che carica css e script, la scrivo una volta sola.
 
Gabriele
 


Rispondevo alle due osservazioni:
"anche usando Joomla! o Wordpress puoi avere la sicurezza"
"Non credo che il cloud di google si possa usare per un sito Web basato 
su PHP+DB"
 
Sono ancora curioso di sapere se qualcuno usa le funzioni da me citate 
con un generatore di siti statici.
 


OK... :-)



 
un paio di settimane fa ho valutato jekyll per una situazione in cui si 
devono gestire 7 blog (che nel tempo cresceranno di numero, al ritmo 
massimo di 1 all'anno) tendenzialmente con i medesimi contenuti (non 
obbligatoriamente ma sarà generalmente così) ma in lingua diversa e 
soprattutto posizionati in subdir di domini diversi, però con un backend 
centralizzato.
 
L'imperativo categorico, dettato da me, era: niente wp sulla macchina 
dove si trova il frontend (sito di e-commerce)
 
Scartato principalmente per il fatto che la gestione degli articoli 
dovrà essere fatta da non dev e quindi il backend di wordpress è molto 
più user friendly rispetto ad una soluzione (che al momento non 
conoscevamo e quindi avremmo dovuto studiare) basata su un qualche 
editor markdown.
Per non parlare di tutti i dettagli che sappiamo come affrontare con 
wordpress mentre con Jekyll sarebbero stati un incognita (e quindi tempo 
perso da un dev per studiare e capire come fare): dalla gestione delle 
sitemap, ai vari aspetti SEO, analytics, ecc...
 
Quindi i contro in quel caso erano:
 
- difficoltà di inserimento contenuti
- assoluta mancanza di dimestichezza con lo strumento che poteva 
comportare perdite di tempo nel far partire il progetto o ritardi in 
tempi successivi qualora spuntassero difficoltà inattese.
 
Abbiamo deviato su wordpress installato su macchina separata e dominio 
di terzo livello dedicato, ma non accessibile al pubblico.
Qui abbiamo attivato la gestione multisite, impostando ogni sito su un 
suo dominio di quarto livello e installato il plugin Simply Static per 
la generazione dei file statici di ogni sito.
 
Al momento stiamo lavorando su uno script che via wget trasferisca ogni 
sito nella sua posizione definitiva (che si trova appunto su macchina 
diversa, altrimenti basterebbe il plugin stesso) ogni volta che viene 
aggiornata la versione statica. Inizialmente partiremo così ma prima o 
poi dovremo mettere mano al plugin perchè rigenera tutto ogni volta e 
così perdiamo il beneficio del mirroring via wget che ci consentirebbe 
di trasferire solo i files nuovi e quelli modificati.
 
In effetti non è il massimo, ma al momento ci risulta più rapido fare 
così. In effetti attualmente il nostro problema è quello di trovare un 
metodo di deploy efficace.
 
 
-- 
Paolo De Dionigi

 metodo di deploy efficace.
 
Script "dos" per comparare i file generati, con eliminazione di quelli 
identici. Non è il massimo dell'efficienza (tempi lunghi di generazione, 
ma non dovrebbe essere un problema) epperò mi sembra abbastanza semplice.
 

aggiornata la versione statica.
 
E rsync?
 
O subversion? :-D
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 * nuvola dei tag * calendario del blog
 
Sono tutte cose (anche l'elenco dei post attinenti) che un generatore di 
siti statici fa senza problemi (se implementate), in quanto sono 
semplicemente liste di cosa che ci sono nel DB del CMS.
 
Che vengano fatte dinamicamente ogni volta che apri la pagina o 
staticamente alla compilazione, cambiano solo le prestazioni. :)
 
Una cosa che un generatore statico non può fare è, per esempio, fare una 
classifica dei post che hanno maggiori commenti, in quanto i commenti sono 
forzatamente su un servizio esterno tipo Disqus. Se Disqus (o chi per 
esso) ti fornisce il widget js da mettere nel sito statico, anche questo 
non è un problema, ma non ho approfondito.
 
Bye.

 di trasferire solo i files nuovi e quelli modificati.
 
Per curiosità: quanto è grande un sito statico generato e quanto 
frequentemente vengono aggiornati i siti?
 
 
-- 
Andrea
 


Purtroppo le immagini incidono (sono blog a supporto di siti di 
e-commerce). Un sito staticizzato con 4 articoli pesa sui 5 Mb e il 
template è super minimal. Diciamo che le immagini incidono per la quasi 
totalità del peso e ovviamente a lungo andare incideranno sempre di più 
percentualmente.
 
L'aggiornamento previsto, se non ricordo male, è di due articoli a 
settimana per ciascun blog.
 
Il prossimo passo, salvo un'idea migliore, sarà quello di studiare il 
meccanismo di creazione delle dir delle immagini in wordpress e usare 
questa logica per istruire uno script a scaricarsi solo quelle create 
dall'ultima attività di sync (ovviamente la data di file e dir non fa 
fede poichè vengono ricreate ogni volta) e scaricare tutto il resto 
indistintamente perchè tanto peserà sempre un'inezia.
 
 
-- 
Paolo De Dionigi


 
e cosa ne dite di un CMS flat file come grav che ho scoperto oggi?