Software applicativi e nuovi TLD: problemi...

Ormai sono centinaia i newTLD disponibili, e centinaia di migliaia (se non milioni...) i nuovi domini registrati di tipo newTLD.
Adesso sta emergendo un problema con diversi software applicativi, che non gestiscono però correttamente questi domini: ad esempio, pare che non si riesca a registrare un nuovo account Skype utilizzando un newTLD, ed anche alcuni browser (per esempio Safari) non risolvono correttamente i newTLD.
Inoltre, molti applicativi che utilizzano indirizzi email come sistema di identificazione degli utenti possono esser soggetti a problemi nell'utilizzo dei newTLD.

A questo proposito ci viene in aiuto Google che, in occasione dell'ultima I/O Conference, ha presentato il tool Domain Test.
Si tratta di un tool gratuito, sviluppato da Google in partnership con Google Registry, Donuts Inc, Uniregistry, e Ausregistry, destinato agli sviluppatori.
E' un progetto open source, disponibile sotto licenza Apache 2, e supporta 126 differenti newTLD.

E' possibile scaricare Domain Test al seguente link: https://github.com/google/domaintest

Come trovare l'indirizzo PEC di un ente

E' risaputo che la PEC (Posta Elettronica Certificata) ha il valore di una raccomandata a/r.

Può capitare che abbiamo necessità di rivolgerci ad un Ente Pubblico, ma non disponiamo del relativo indirizzo PEC... (alcuni Enti sembrano tutelare questa informazione quasi fosse un segreto... solo un modo per disincentivarne l'uso? Indifferente...)

Fortunatamente, esiste un servizio-indice della Pubblica Amministrazione, in cui è possibile reperire tutte le informazioni relative alla PEC ufficiale di ogni Ufficio o Ente

Questo servizio, si trova al seguente link: http://www.indicepa.gov.it/
E, attraverso il relativo motore di ricerca, è abbastanza agevole individuare l'Ente di cui stiamo cercando i dati...

Al momento di questo post (luglio 2014) in questo vero e proprio "Indice delle Pubbliche Amministrazioni" sono reperibili i dati di 20.991 Enti Accreditati, 54.234 Unità Organizzative, 17.752 Uffici di Protocollo, 79.806 indirizzi PEC e 29.851 Servizi di fatturazione elettronica.

Heartbleed

Sul bug Heartbleed  in questi giorni si sta leggendo di tutto, Quindi, a me resta ben poco da scrivere senza correre il rischio di ripetere solo quanto già scritto (probabilmente meglio) da altri.

Mi limito semplicemente a specificare quali sono esattamente le versioni affette dal bug:

OpenSSL 1.0.1
OpenSSL 1.0.1f
OpenSSL 1.0.2-beta
OpenSSL 1.0.2-beta1

Se non usate queste versioni, allora potete stare tranquilli.
Se invece state usando una di queste versioni, non si capisce perché stiate perdendo tempo a leggere il mio blog invece di precipitarvi ad installare il relativo aggiornamento sul vostro server.

A quanti invece si domandassero in cosa esattamente consistente questo bug, rispondo con una splendida striscia che - meglio di mille parole - spiega efficacemente il problema:

Arrivederci, Uriel...

Non so se qualcuno di voi seguiva il celebre blog di Uriel: originariamente wolfstep.cc, negli ultimi anni keinpfusch.net

Una presenza storica per l'Italia di internet: il suo blog aveva più di dieci anni, contava centinaia di post e centinaia di migliaia di commenti. Leggerlo era sempre un piacere, anche quando (abbastanza raramente) le sue idee non erano condivisibili.

Qualche anno fa era emigrato con la famiglia in Germania, e si era tolto la soddisfazione di pubblicare sul suo blog questo disclaimer:

Il titolare di questo blog e' residente in Germania , non piu' in Italia, e pertanto risponde di quel che scrive solo alla giustizia tedesca.Il tribunale competente e' quello di Duisburg (NRW). Di conseguenza, me ne FREGO delle leggi-bavaglio contro i blog. Non pubblichero' smentite, non correggero' quel che dico, non usero' un linguaggio diverso, non seguiro' nessuna delle bislacche farneticazioni partorite dal parlamento italiano, e specialmente: se sei un coglione, ti chiamero' proprio "coglione". Get used to it.

Oggi il suo blog si è "svuotato", e compare questo unico post:

Finisce qui.

Questo e' davvero l'ultimo post di questo blog. Da quanto ho aperto, sono sempre stato preoccupato per il crescente numero di lettori. Perche' in Italia NON PUOI avere certi numeri senza che qualcuno decida che deve calcare il TUO palcoscenico, a costo di spararti pur di farsi notare.
La pressione oggi e' diventata eccessiva, al punto che ho valutato di rivolgermi alle  autorita'.
Le quali hanno fatto una copia del vecchio blog, e ovviamente mi hanno suggerito di smetterla di scrivere. Non possono obbligarmi siccome io sono il denunciante, ma ovviamente lo consigliano in questi casi.
 E' assai difficile pensare che in Italia NON PUOI dire quel che pensi se sei uno solo. Loro sono "tutti". E odiano, odiano , odiano. Odiano con l'odio di popoli che odiano per secoli, che vivono nell'odio, che fanno dell'odio la loro ragione di vita. Deludente.
Ma oggi ho capito che sono io che devo realizzare qualcosa.
Che non sono in Italia.
Non sono tedesco, e probabilmente non lo saro' mai. Ma il punto e' che se quella e' l'italia, se e' un posto dove oltre un certo limite scatta l'odio, di certo non sono nemmeno italiano. Io non vado a minacciare le persone e le loro famiglie se hanno un blog che dice cose su cui non sono d'accordo.
Tantomeno sono mai andato a minacciare persone o famiglie per invidia/odio riguardo al numero di lettori. Non sono fatto di quella sostanza.
Ma qualcun altro si. E cosi', adesso ci pensera' la polizia tedesca, che poi passera' la palla a quella italiana.


Il Papa (non che io sia diventato religioso, voglio dire, non mi spiace sino a questo punto!) ha fatto una domanda ad alcuni studenti belgi, chiedendo loro su cosa poggi il loro cuore. Dove sia il centro della loro persona.
Di certo da oggi non poggia piu' in Italia. Non sento di avere piu' qualcosa da scrivere per, di scrivere a, di scrivere su, un paese cosi' deludente.
Come ho scritto, non sono tedesco. E non lo saro' mai. Di certo, se tutto questo succede per avere un blog che viene letto, se c'e' gente capace di tirare di mezzo donne e bambini per invidia, non sono nemmeno italiano.
Spetta a me capire su cosa poggi il mio cuore, e ci vorra' del tempo. Ma di certo, l'Italia e' passata.
Finisce qui. Forse apriro' qualcosa in tedesco, tra qualche mese, appena il mio tedesco scritto sara' decente. Ma di certo, finisce qui.
E' stato bello, ma adesso e' tempo di godersi la Rete da puri lettori.
Cosa ho imparato da questo? Una cosa semplice.
Che i pregiudizi sono scienze esatte, col senno di poi.
Tutti, ma proprio tutti.
Oggi, ho davvero lasciato l' Italia.
Magari scrivero' qualcosa su I2P, ancora non so. Devo vedere se ne ho ancora voglia.

A cui, poche ore dopo, se ne è aggiunto un altro: Epilogo.

Triste, vero?
Mi chiedo cosa ci faccia la gente intelligente ancora in Italia. Infatti sono ben pochi quelli che restano...

Ho il rimpianto di non poterlo più leggere, ed ho il rimpianto di non essermi tempo fa registrato ai suoi feed per email: adesso avrei un bell'archivio dei suoi scritti, senza dover ricorrere alla scomodissima internet wayback machine...

Perché conviene mantenere valori TTL elevati

Io sono convinto che, a meno che non siano previste a breve modifiche dei DNS, per gli stessi conviene mantenere un valore di TTL più elevato possibile.
(Se non sapete cos'è il TTL dei DNS, Wikipedia fa miracoli)

Vi segnalo questo post (che merita leggere integralmente: è un vero e proprio racconto dell'orrore informatico!) che si conclude confermando questa mia convinzione:

In addition, I also strongly suggest you to use a longer TTL for the MX record, just in case. It was 1 hour TTL in my case and that’s why I didn’t have enough time to keep receiving emails to the compromised domain after losing the DNS control. If it was a week-long TTL for example, I would have had a greater chance to recover the stolen accounts.

Si tratta comunque di una storia a lieto fine: Naoki Hiroshima alla fine è riuscito a farsi ri-assegnare da Twitter il proprio account @N

Un utile plugin per WordPress: Redirection

Il mio lavoro di questa settimana è consistito nel prendere i brandelli di un vecchio sito di un centinaio di pagine, realizzato con un primitivo CMS, e dargli una rinfrescata, migrandolo sotto WordPress e ristrutturandone i contenuti in funzione di tag e categorie.

Lavoro di per sé abbastanza veloce, e forse anche un po' divertente.

La parte triste è arrivata alla fine: il sito originale (che, peraltro, era anche abbastanza ben indicizzato e trafficato) aveva una struttura di link per ogni pagina del tipo:

www.dominio.ext/ ​?View=entry&EntryID=9364

(dal punto di vista SEO, il massimo del minimo...)
Mentre WordPress, scegliendo di fargli usare URL SEO-friendly, genera qualcosa del tipo

www.dominio.ext/come-smacchiare-giaguari/

Quindi era importante:

• non perdere le visite in ingresso provenienti dai motori di ricerca (che hanno indicizzato ancora le vecchie pagine)
• non perdere le indicizzazioni ed il posizionamento delle vecchie pagine

Per farlo, bisogna realizzare un redirect; anzi, precisamente un redirect di tipo 301

Ci sono moltissime maniere per farlo, ma ho scoperto il plugin Redirection che rende l'operazione particolarmente comoda.

Questo plugin permette di impostare un numero qualsiasi di redirect, facendo per esempio in modo che le visite in arrivo all'URL www.dominio.ext/ ​?View=entry&EntryID=9364 vengano automaticamente reindirizzate, con un redirect 301, sulla corrispondente nuova pagina www.dominio.ext/come-smacchiare-giaguari/

Molto facile da installare e configurare (per impostare tutto il centinaio di redirect non ho impiegato più di un'ora), comprende anche altre funzioni molto importanti:

• tiene traccia degli errori di tipo 404 (pagina non trovata); in tal modo, riusciamo a renderci conto se ci siamo "persi per strada" qualche pagina, oppure se da qualche parte hanno inserito un link errato verso il nostro sito.
• indica, per ogni redirect, il numero di volte che è stato utilizzato per traffico in ingresso (ed in tal modo possiamo anche vedere quali siano i link "vecchi" più popolari e quanto a lungo sopravvivano in giro per la rete)
• permette di creare regole di redirect basate anche sul browser utilizzato dall'utente, o sul sito referral, o sul fatto che l'utente abbia fatto login o meno
• permette di importare il file .htaccess
• e può esportare le regole di redirect in formato CSV, XML, o come file .htaccess di Apache

Infine (male non fa), si tratta di un plugin gratuito.

Insomma, Redirection è un plugin completo, funzionale ed efficiente: ve lo consiglio!

IP nuovo, vita nuova?

La lotta allo spam sta diventando sempre più serrata, le blacklist si inventano tecniche sempre più sofisticate per individuare (e bloccare) gli spammer, e quindi se vogliamo gestire in proprio il nostro server email dobbiamo imparare a fare le cose per benino, configurandolo correttamente da subito...

In particolare se si tratta di un server "nuovo" e che utilizza un IP "vergine" (ossia un IP che in precedenza non è mai stato utilizzato per l'invio di email), è di fondamentale importanza partire bene da subito: ovvero, prima dell'invio della prima mail, il server dovrà essere configurato correttamente, completo anche di DKIM ed SPF: altrimenti, l'inserimento immediato nelle blacklist dei grossi provider è quasi garantito.

Perché non tutti i server DNS funzionano per i domini .it?

Negli helpdesk dei Registrar, o nei forum specializzati capita frequentemente una segnalazione in merito a problemi di configurazione di server DNS per i domini .it (un esempio recente qui... ma con google potreste trovarne dozzine, se non centinaia!!!); una segnalazione che si può efficacemente riassumere con:

Ci sono questi server DNS che ho SEMPRE usato per tutti i miei domini, che funzionano BENISSIMO, che non hanno MAI avuto alcun problema... ed allora perché ho sempre rogne se voglio usarli per un dominio .it?

Ed il lamento prosegue cercando di attribuire la colpa al Registrar, al nic.it, o ad oscure congiunzioni astrali...

E' il caso di specificare un concetto che, molto spesso, sfugge:

Il nic.it, prima di registrare un dominio assegnandolo a determinati server DNS, oppure prima di accettare che i server DNS già attivi per un certo dominio vengano sostituiti con altri, esegue sui "nuovi" server DNS alcuni test.
E se questi test non vengono superati, l'operazione non viene effettuata.
Quindi:

• se si tratta di una nuova registrazione, il nic.it andrà avanti per un po' di tempo ad effettuare il test; se i server DNS continuano a non superarlo, ad un certo punto il nic.it cancellerà semplicemente la registrazione, il dominio tornerà ad essere libero per una nuova registrazione, e chi s'è visto s'è visto;
  
• se si tratta invece di sostituire i server DNS per un dominio già registrato, il nic.it continuerà ad eseguire i test dino a che non saranno superati; nel frattempo, resteranno sempre attivi i nuovi server DNS.
  Dopo un po' di tempo, se i server DNS continueranno a non superare il test, allora il nic.it abbandonerà l'operazione ed il dominio resterà con i vecchi server DNS

Chiaro?

Vediamo adesso alcuni dettagli:

In cosa consistono i test eseguiti dal nic.it sui server DNS?

I requisiti sono i seguenti:

• i server DNS autoritativi per il nic.it devono essere almeno 2 (due) e devono corrispondere esattamente a quelli presenti nella registrazione del nome a dominio;
• gli indirizzi IP degli host presenti nella registrazione del nome a dominio devono  corrispondere a quelli ad essi realmente associati nel DNS;
• al nome a dominio non può essere associato un record CNAME;
• il nome del nameserver specificato nel record SOA non può essere un CNAME;
• i nomi dei nameserver autoritativi per il nome a dominio non possono essere dei CNAME;
• al record MX, eventualmente presente, non può essere associato un CNAME;
• durante la procedura di controllo, nessuno dei server DNS deve dare alcuno dei seguenti esiti:
  Not responding
  Not reachable
  Not running
  Non-existent domain
  Host not found
  Server failure
  Query failed
• tutti gli host presenti nella registrazione devono essere autoritativi per il nome a dominio registrato.

Come faccio a verificare che i miei server DNS sono correttamente configurati?

Una volta il nic.it forniva un tool on-line di verifica e diagnosi dei server DNS; purtroppo questo tool non è più pubblico, ma è solo a disposizione dei Registrar.

Quindi, per verificare i nostri server DNS il modo più semplice è, ovviamente, quello di lasciare che il nic.it faccia il test: se i server DNS sono correttamente configurati, il test verrà superato e quindi significa che è tutto OK.
In alternativa, se vogliamo fare una diagnosi approfondita, dovremmo chiedere al nostro Registrar. Ma ovviamente ciò può portare a qualche problema: non tutti i Registrar sono disponibili a farlo, non tutti sono disponibili a farlo gratis, e non tutti ancora sono disponibili a farlo velocemente...
(Peraltro, bisogna anche capirli: un Registrar solitamente mette a disposizione dei server DNS funzionanti; se noi vogliamo usare i nostri server DNS anziché quelli del Registrar, perché lo stesso dovrebbe farsi carico - gratis e velocemente - delle rogne relative ai NOSTRI server DNS?)
Esistono una serie di tools gratuiti on line che ti permettono di verificare la configurazione dei DNS (quali ad esempio dnsqueries.com), ma obiettivamente non ne ho trovato ancora uno completo ed approfondito come quello del nic.it...
Il problema principale è che i normali tool disponibili in rete fanno un controllo dello stato dei DNS per i server DNS già impostati dal Registro come autoritativi; mentre a noi spesso interessa effettuare il test di confromità per dei server DNS che NON sono ancora riconosciuti dal Registro come autoritativi...
Se voi conoscete qualche tool diagnostico valido e che risolva questo problema, pls segnalatemelo nei commenti.

Per quanto tempo il nic.it testerà i server DNS prima di bocciarli?

Per cinque giorni.
Se al termine dei cinque giorni i nuovi server DNS non avranno superato il test, la richiesta verrà cancellata.

Ma perché i miei server DNS funzionano benissimo per i gTLD e danno problemi solo con i .it?

Semplice. Per i gTLD non viene effettuato NESSUN test: quindi, i server DNS possono essere malconfigurati, non rispondere, o anche non esistere proprio... e nessuno se ne accorgerà (tranne, ovviamente, chi cercherà il tuo sito).
Ma il Registro non recriminerà certamente.
Viceversa, per i .it il nic.it pretende (giustamente) che i server DNS siano perfettamente configurati.
Quindi, non è che "danno problemi solo per i .it": il problema c'è per tutti i domini gestiti attraverso quei DNS, solo che magari non ce se ne accorge... ma il problema c'è e resta, e magari si tradurrà in saltuari ed apparentemente casuali problemi di propagazione, o da altri ed apparentemente casuali che poi tenderemo a sottovalutare... "Capitano solo a te, nessun altro segnala problemi del genere..."

  

Il tuo dominio .it è al sicuro?

Vi esporrò oggi un aspetto abbastanza delicato relativo alla registrazione e gestione dei domini .it.
E' un aspetto che coinvolge direttamente la sicurezza del dominio e che, pur non rappresentando una vera e propria vulnerabilità, essendo per lo più sottovalutato se non addirittura ignorato, costituisce almeno una grave criticità.

Andiamo con ordine.

Per poter trasferire presso un altro Registrar un dominio .it, è necessario un codice alfanumerico (cosiddetto "authinfo", o "authcode"). Ovvero, al nuovo Registrar dobbiamo fornire questo codice, altrimenti trasferire il dominio sarà impossibile.
Fino a qui nulla di strano: questo meccanismo è comune a moltissimi altri ccTLD ed ai gTLD

Però ci sono due dettagli che differenziano il meccanismo di trasferimento dei domini .it rispetto a quello (universalmente noto) dei gTLD:

1. nei domini .it, il codice authinfo viene generato dal Registrar all'atto della registrazione/trasferimento del dominio, e viene immediatamente comunicato a mezzo email al Registrante (nei gTLD invece di norma il Registrante lo deve esplicitamente richiedere al Registrar, che comunque è obbligato a fornirlo entro 5 giorni dalla richiesta)
   
2. nei gTLD, dopo aver avviato il trasferimento presso un altro Registrar fornendo l'authinfo, il Registrante dovrà dare un'ulteriore conferma a mezzo email (normalmente, il Registrante riceve un'email con un link: se clicca sul link dà conferma del trasferimento, altrimenti lo stesso, pochi giorni dopo, viene abbandonato e fallisce)

La prima criticità è che il codice authinfo viene fornito al Registrante immediatamente, al momento della registrazione.

Se tutti i Registranti fossero ben consci dell'importanza di questo codice, non ci sarebbe alcun problema; però in realtà ciò non è. Moltissimi Registranti non sanno neppure cosa sia, né a cosa serva, e quindi non lo conservano con le dovute attenzioni. Nel migliore dei casi si limiteranno a lasciare la relativa email in mezzo alle altre, senza cancellarla e senza proteggerla in nessuna maniera particolare.

Però un archivio email è soggetto a tantissime vulnerabilità: può esser violato da un virus o da un malware, oppure può capitare che se ne dia l'accesso (magari ripromettendosi che sia solo "temporaneamente") ad un collega, ad un tecnico, ad un amico, a quella che oggi è nostra moglie ma domani diventerà "la nostra ex moglie"... in tutti questi casi queste figure avranno la possibilità di accedere al codice authinfo, di un dominio che magari abbiamo registrato tre anni prima... e, nel momento del bisogno, potrebbero decidere di farne un uso illecito.

La seconda criticità consiste nel fatto che dopo l'avvio di un trasferimento non viene richiesta nessuna conferma via email al Registrante; quindi, questi non ha la possibilità di bloccarlo o anche solo di accorgersene fino a che non sarà troppo tardi.

Facciamo un esempio concreto.

Voi oggi registrate un dominio .it presso il Registrar $Registrar1.
Come email di riferimento indicate la vostra email personale, quella che utilizzate normalmente ogni giorno, e che consultate quotidianamente dal notebook, dallo smartphone, dal PC dell'ufficio e financo - via webmail - ogni tanto anche da PC "altri" (quello di un amico presso cui siete in ferie, quello di un cybercafè ecc.)

$Registrar1 vi manda - correttamente - il codice authinfo. Voi lo vedete, sovrappensiero ci chiedete "Cos'è 'sta roba?", e lo dimenticate là. O al massimo, se siete ordinati, lo spostate in una cartella apposita.

Nel corso dei tre anni successivi, possono capitare uno (o più di uno) dei seguenti episodi:

• uno qualsiasi degli apparati utilizzati (compreso il PC del cybercafè...) viene infettato da un virus
• il vostro notebook va in assistenza, ed al tecnico fornirete la password di accesso
• vi siete trovati nella necessità di comunicare la password dell'email ad un collega, che vi sostituisce durante un periodo di ferie o malattia
• vi hanno rubato (o avete smarrito) lo smartphone
• durante un viaggio all'estero, vi siete collegati ad internet per controllare la posta; e lo avete fatto attraverso una rete wi-fi che avete trovato "aperta" (compiacendovi tra di voi perché siete riusciti a "navigare gratis", senza pagare il salatissimo conto del roaming...)
• ... o altre dozzine di episodi simili

In tutte queste situazioni, qualcuno avrebbe potuto ottenere l'accesso alla vostra email e, quindi, accedere anche al codice authinfo del vostro dominio. E magari annotarselo, per farne eventualmente uso alla bisogna... "non si sa mai".
O magari il vostro collega, dopo essersi collegato alla vostra mail, ha sbadatamente conservato sul proprio PC una copia completa degli archivi, e dopo il PC gli è stato rubato, o affidato ad un altro collega (che magari ce l'ha con voi per motivi personali) senza stare troppo a badare su quello che c'era e non c'era su quel PC... insomma, le possibilità a questo punto sono pressoché infinite.

Quindi, partiamo dal presupposto: un malintenzionato (che può essere l'autore di un virus, un vostro collega o ex-collega che non vi vuole bene, la vostra ex-moglie, il tecnico del PC a cui non avete pagato una fattura, ecc. ecc.) a questo punto ha l'authinfo del vostro dominio.

Cosa deve fare?

Semplice: scegliersi un altro Registrar accreditato (che chiameremo $Registrar2) accreditato, chiedere il trasferimento del dominio fornendo il relativo authinfo e, nell'occasione, cambiando i dati del registrante (con altri falsi, fittizi, o con dati veri ed effettivi di una persona qualsiasi, del tutto inconsapevole).

A questo punto, a meno che non ve ne accorgiate per puro caso, il dominio sarà trasferito, e sarà controllato dal malintenzionato.

E dico che ve ne potete accorgere solo per puro caso perché, di norma, non viene inviato al Registrar nessun avviso del tipo "guarda che stiamo trasferendo il tuo dominio"... e la cosa si scopre di solito quando ormai la frittata è fatta.

Inoltre, il tempo per accorgersene è anche molto limitato: al massimo tre giorni (ma possono anche esser di meno). E, anche se ve ne accorgete, non è detto che $Registrar1 sia disposto a collaborare per interrompere il trasferimento (in teoria, potrebbe farlo solo in seguito ad un ordine dell'autorità giudiziaria), né che sia abbastanza tempestivo da riuscirci...  

Possibili scenari:

• accettate le condizioni dettate dal malintenzionate, quali che siano 
• fate una procedura di opposizione al NIC, ed incrociate le dita (se va tutto bene, comunque ci vorranno alcuni mesi, alcune migliaia di euro di spesa, ed il risultato soprattutto non è scontato)
• vi scegliete un altro nome a dominio e su quello che avete perso ci mettete una bella pietra sopra (compreso il posizionamento dello stesso, i backlink, il fatto che tot centinaia di clienti e collaboratori lo conoscono ed usano email appoggiate a questo dominio ecc.)

Come fare per evitarlo?

La soluzione, in questo caso, è semplice: è sufficiente che siate consci dell'importanza dell'authinfo di un dominio .it, e che quindi lo conserviate con le dovute cautele, come se fosse una password preziosa (quale, di fatto, è).

Tra i "modi corretti e sicuri" per conservarlo cito ad esempio i due più semplici:

• stampatelo su carta, riponetelo in una busta sigillata, scrivete sulla busta "contiene authinfo del dominio xxxxxyyyyyzzzzzz.it" e la busta sigillata conservatela in cassaforte;
  
• conservatelo in una chiavetta USB con crittografia hardware e protetta da password (non spaventatevi: costano pochi euro in più rispetto ad una normale chiavetta USB!)

Adottando uno di questi semplici accorgimenti, ridurrete di molto le possibilità di furto del vostro dominio, e potrete dormire sonni relativamente più tranquilli. (E scrivo "relativamente" perché esistono anche altre vulnerabilità... ma di queste magari ne scriverò un'altra volta...)

Si scrive "WordPress", non "Wordpress"!!!!

image credit to Norebbo

Può sembrare una sciocchezza, ma in realtà è importante... scrivere "Wordpress" è sbagliato, la grafia corretta è "WordPress", con la W e la P maiuscole.
Una sola parole, due lettere maiuscole: W e P.

Parimenti, sono sbagliate anche altre grafie, quali ad esempio wordpress, word press, Word Press... la grafia giusta è una sola, ed è WordPress.

Perché è tanto importante?

Intanto, per non apparire sciatti. Un errore di grafia è sempre fastidioso, ed è un sintomo di trascuratezza e disordine.
E se la community di WordPress ha deciso che si scrive WordPress, è così e basta.

Poi perché in WordPress è addirittura presente una funzione (  capital_P_dangit() ) che ha proprio lo scopo di correggere automaticamente la grafia sbagliata di WordPress, sostituendola con quella giusta.
Il che, se non prendete la sana abitudine di scrivere sempre "WordPress" correttamente, potrebbe causarvi qualche problemino...
Infatti questa funzione talvolta interviene anche sugli URL. Quindi se, per esempio, avete installato WordPress in una directory che si chiana /Wordpress ... beh, potreste avere qualche problemino con i link.

NOTA: proprio volendo, è possibile disabilitare la funzione: per farlo, è sufficiente inserire nel file functions.php le seguenti righe di codice:

remove_filter( 'the_title', 'capital_P_dangit', 11 );
remove_filter( 'the_content', 'capital_P_dangit', 11 );
remove_filter( 'comment_text', 'capital_P_dangit', 31 );

Oppure esistono degli appositi plugin, quali ad esempio Remove WordPress to WordPress filter
Ma sconsiglio di farlo, e piuttosto abituatevi a scrivere WordPress.
Non è difficile, ce la potete fare...

Perché questo blog è su Blogspot.com anziché su WordPress.com?

La domanda può sorgere spontanea: perché - visto che parlo anche di WordPress - questo blog è su Blogspot.com anziché su WordPress.com?

Effettivamente è una bella domanda, alla quale però è possibile dare al massimo una risposta mediocre...

Cominciamo ad analizzare i possibili motivi, magari andando per esclusione... e cercando, soprattutto, di restar fuori da quella che, nel web, sembra esser diventata una "guerra di religione" che vede su opposti fronti i fedeli seguaci di Wordpress confrontarsi con gli altrettanto fedeli seguaci di Blogspot.com...

Non è una questione di soldi

Sia Blogspot.com che WordPress.org sono piattaforme gratuite; e le risorse che mettono a disposizione sono - obiettivamente - superiori a quelle di cui potrei aver mai ragionevolmente aver bisogno per questo blog

Non è una questione di temi disponibili

Entrambe le piattaforme mettono a disposizione un certo numero di temi gratuiti; hanno il problema di essere "temi standard", ma tutto sommato... chi se ne frega? Sono comunque migliori di qualsiasi tema io potrei mai costruirmi "a mano", e spesso l'illusione di "poter fare di meglio" è - appunto - solo un illusione.
Però, volendo, su blogspot.com posso modificare i temi esistenti o anche costruirmene uno del tutto nuovo (sottolineo: volendolo. Ed in questo momento la cosa non mi passa neppure per l'anticamera del cervello...)
Mentre su WordPress.com dovrei necessariamente passare su un servizio di hosting a pagamento.
Quindi, proprio volendo: un punto a Grifondoro... pardon, Blogspot.com

Annunci Adsense

In questo momento il mio blog ha un traffico ridicolo, e quindi altrettanto ridicola sarebbe l'idea di farci dei soldi pubblicando annunci Adsense.
Però, se un domani dovesse avere successo e dovesse cominciare ad avere migliaia di visitatori entusiasti, potrei anche pensare di guadagnarci una pizza una ogni tanto con gli annunci Adsense.
Su Blogspot.com posso farlo, su WordPress.com invece no.
Un altro punto a Blogspot.com

Widget Javascript

Nel caso volessi installare un widget Javascript qualsiasi, su Blogspot.com posso farlo tranquillamente, su WordPress.com invece no.
Ancora un punto per Blogspot.com

Dominio personalizzato

Se avessi il mio nome a dominio personalizzato (o se dovessi domani decidere di registrarlo), con Blogspot.com potrò associarlo al mio blog gratuitamente, con WordPress.com invece dovrò necessariamente pagare qualcosa...
Il distacco a favore di Blogspot.com aumenta di un altro punto.

SEO & indicizzazione

Blogspot.com è una piattaforma di proprietà di Google.
PARE (e, in definitiva, è ragionevole che sia così...) che Google guardi "con un occhio di riguardo" all'indicizzazione di blog ospitati su Blogspot.com
Personalmente, ho potuto ad esempio verificare che - in alcuni casi particolari - un blog su Blogspot.com risultava già indicizzato pochi secondi dopo la creazione.
Forse questo "favoritismo" si potrebbe compensare implementando sul blog su WordPress.com alcune opportune tecniche SEO... ma perché complicarsi la vita?

Quindi, tutto sommato, anche se WordPress mi piace e  lo conosco, di motivi per cui sia preferibile la piattaforma Blogspot.com per un blog personale o amatoriale ce ne sono parecchi...

Il discorso cambia se si tratta di un blog professionale; ma con questo non voglio dire che "per un blog professionale è meglio WordPress", ma solo che - in questo caso - sono ANCHE altri fattori da dover esser presi in considerazione... ed il risultato non sarà così scontato.
Però magari ne parleremo un'altra volta, eh?

WordPress: come vuotare il cestino

image credit by Norebbo

Ogni volta che cancelli un post, una pagina o un commento, Wordpress ne conserverà una copia nel cestino: non si sa mai...
Per cancellare la copia dal cestino, è necessario andare nella relativa cartella e cancellare da lì i file.
Il cestino viene vuotato ogni 30 giorni, ma questo tempo può essere ridotto a piacimento modificando il file wp-config.php

Inserendo la riga

define ('EMPTY_TRASH_DAYS', 5);

il cestino verrà vuotato automaticamente ogni 5 giorni.

Se vuoi disabilitare del tutto il cestino, e fare in modo che ogni elemento venga immediatamente cancellato senza possibilità di recupero (attenzione, che di questo un giorno potresti pentirti...), basterà inserire la riga:

define ('EMPTY_TRASH_DAYS', 0);

WordPress: come evitare i commenti troppo corti

image credit to Norebbo

Capita spesso che gli utenti lascino solo inutili commenti troppo brevi: "Bene!", "Approvo!", "Ben detto!"...
Spesso si tratta di commenti inutili, che non aggiungono nulla all'interazione e, anzi, possono sviare il lettore distraendolo da altri commenti più pertinenti e pregnanti.

Con poche righe di codice possiamo costringfere i nostri utenti a inserire commenti solo di una lunghezza minima che possiamo stabilire.

E' sufficiente aggiungere a functions.php le seguenti righe di codice:




add_filter( 'preprocess_comment', 'minimal_comment_length' );

function minimal_comment_length( $commentdata ) {

$minimalCommentLength = 30;

if ( strlen( trim( $commentdata['comment_content'] ) ) < $minimalCommentLength ){

wp_die( 'Tutti i commenti devono essere lunghi almeno ' . $minimalCommentLength . ' caratteri.' );

}

return $commentdata;

}

NOTE:

• $minimalCommentLength deve essere impostato al numero minimo di caratteri desiderato (nell'esempio: 30 caratteri)
• E' risaputo che è impossibile fare qualcosa a prova di stupido, perchè gli stupidi sono troppo ingegnosi; quindi, sicuramente ci sarà qualche imbecille che risolverà inserendo come commento "Beneeee!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!".
  Peraltro, sappiamo di non vivere in un mondo perfetto...