Jetpack e le statistiche perse

A quanto pare non ho più le statistiche di 5 anni di questo blog, statistiche che andavano dal febbraio 2007 fino al 6 gennaio 2012 e che teneva wordpress.com. Me ne sono accorto per caso, non essendo un fanatico di questi dati. Oggi aprendo la pagina delle statistiche (ogni tanto lo faccio), vedo che risalgono al massimo al 7 gennaio scorso. Non so cosa sia successo e non dipende dal passaggio al nuovo hosting.

Cercando in rete, ho trovato un thread sul forum di wordpress.org dove altri hanno riscontrato questo stesso problema. Uno degli intervenuti suggerisce di controllare nel database MySQL l’id del blog che viene collegato al proprio account su wordpress.com perché pare che l’ultimo aggiornamento di Jetpack lo cambi. Controllo ed effettivamente è successo questo anche a me. Ho aperto infatti i file .sql dei vari backup che faccio giornalmente e infatti fino al 6 gennaio ha un certo blog_id mentre a partire dal 7 ne trovo un altro. Questi backup sono quelli che avevo su Aruba, ecco perché dicevo che il cambio di hosting non c’entra nulla.

Ho provato a modificare l’id del blog a mano, nulla; ho provato a cambiare anche i token associati all’utente e al blog, nulla. Ho provato, infine, a eliminare del tutto Jetpack disinstallandolo ed eliminando i dati, nulla. Ho provato a installare il vecchio WordPress.com Stats, visto che la tabella coi suoi vecchi dati c’è ancora (e conserva il vecchio blog_id) ma la dashboard mi dice: “Your WordPress.com account is not authorized to view the stats of this blog.”. Se provo, infine, ad andare su https://dashboard.wordpress.com/wp-admin/index.php?page=stats&blog=xxxyyy (dove “xxxyyy” è il blog_id) non ho i permessi per visualizzare la pagina.

Ho contattato l’assistenza di wordpress.com, ma non so perché qualcosa mi dice che sarà invano. Speriamo di no.

A voi è successo?

Aggiornamento: problema risolto qui.

Offuscare le email: lo shortcode per WordPress

WordPress ha una funzione poco nota, messa alcuni giorni fa in evidenza da WP Recipes e poi ripresa da Panese. La funzione si chiama antispambot e serve ad offuscare gli indirizzi email ai crawler finalizzati allo spam.

Vorrei spendere, però, qualche parola in più sul suo funzionamento.
Continua a leggere

Le variabili relative alle pagine in WordPress

Visto che per l’ennesima volta mi sono scordato di appuntarmi in Tomboy il contenuto di queste variabili, lo faccio adesso anche sul blog, così magari vi tornano utili.

Si tratta di alcune variabili globali di WordPress relative alla paginazione di post (quando leggete “post” intendo dire articolo e pagina statica) e di pagine d’archivio. Trovate segnalato se la variabile va usata all’interno del loop; per dichiararla globale si usa global $variabile;.

Variabili globali di post e pagina

$multipage

Dice se un post è suddiviso in più pagine o no. Va usata nel loop.
Ad esempio, se un post è suddiviso in 5 pagine, il valore sarà true.

$numpages

Contiene il numero di pagine di un post suddiviso in più pagine. Va usata nel loop.
Ad esempio, se un post è suddiviso in 5 pagine, il valore sarà 5.

$page

Contiene il numero di pagina visualizzata di un post suddiviso in più pagine.
Ad esempio, se stiamo visualizzando la pagina 3 di un post suddiviso in 5 pagine, il valore sarà 3.

$pages

È un array contenente tanti elementi quante sono le pagine di un post. Va usato nel loop.
Ad esempio, se un post è suddiviso in 3 pagine, l’array conterrà 3 elementi (0, 1, 2) e ciascun elemento conterrà una parte del post.

Variabili globali d’archivio

$paged

Contiene il numero di pagina visualizzata di un archivio.
Ad esempio, se stiamo vedendo la pagina 5 dell’archivio del tag “wordpress”, il valore sarà 5.

$wp_query->max_num_pages

Contiene il numero totale di pagine in cui un archivio è suddiviso. Non è una variabile globale, ma un elemento dell’array $wp_query, che quindi andrà dichiarato globalmente (global $wp_query;)
Ad esempio, se abbiamo impostato WordPress per mostrare 5 post per pagina e abbiamo 20 post con tag “wordpress”, il valore sarà 4 per la pagina d’archivio del tag “wordpress”.

Spostare WordPress: i consigli degli esperti

Nella giornata di ieri del WordCamp di Milano, Andrea Beggi ha proposto un interessante intervento (qui il video registrato) su un argomento che ha affrontato più volte sul suo blog: come spostare la propria installazione di WordPress da un hosting (un hosting in senso stretto o VPS o server dedicato) a un altro. Di questo intervento ha anche rilasciato i suoi appunti nel suo post di oggi (qui le slide).

Tra i miei segnalibri su Delicious ho ripescato quelli che mi sono conservato su questo argomento e ve li ripropongo qui sotto.

Il Codex di WordPress

Andrea Beggi

Joost de Valk (aka Yoast)

Vladimir Prelovac

Steve Taylor

Penso sia sempre bene ascoltare più voci e, come vedete, gli autori sono tra i più noti su WordPress.

Autenticazione multifattoriale con Perfect Paper Passwords

Qualche mese fa ho scritto un post sul plugin One-Time Password che ha lo scopo di rendere più sicura l’autenticazione nella propria area amministrativa di WordPress mediante l’uso dell’omonima tecnica detta One-Time Password. In breve, con questo sistema possiamo autenticarci alla Bacheca di WordPress usando una password usa-e-getta che può sostituire la password di WordPress (ottimo in caso di utilizzo in un Internet Cafè) o aggiungersi ad essa.

Oltre a questo plugin, ne esiste un altro che fa qualcosa di molto simile: Perfect Paper Passwords. Con esso avrete a disposizione una password usa-e-getta che si aggiunge (e non si sostituisce) a quella di WordPress.

Autenticazione forte

Sappiamo che per autenticarsi a un sistema informatico con ragionevole sicurezza è buona cosa utilizzare un’autenticazione a due fattori:

  • qualcosa che si sa (username e password)
  • qualcosa che si ha (un oggetto, che può essere un token, una smartcard, una chiavetta USB, la SIM del telefono, la biometria o anche un semplice taccuino con password usa-e-getta.

Questo è anche il sistema usato da molte banche per i loro servizi online. In questo modo, anche se un malintenzionato dovesse entrare in possesso delle vostre credenziali, non potrebbe accedere al sistema perché non ha il secondo fattore di autenticazione, il quale appunto cambia continuamente.

Questo plugin vi dà la possibilità di implementare in WordPress il sistema OTP in modo facile e gratuito.
Continua a leggere

Quando il feed RSS di WordPress fa i capricci

Ricordo che anni fa capitò anche a me. Allora non ero così a mio agio nei meandri di questo CMS e la cosa mi spiazzò. In parole semplici, il feed RSS di WordPress non veniva convalidato dai browser e nemmeno da FeedBurner, rimanendo quindi irraggiungibile per i lettori: c’era un errore nel parsing del file XML. Ricordo bene che il problema era dovuto a qualche riga vuota all’inizio (o alla fine) del file, ma non ricordo come ne uscii. Avrò senz’altro cercato aiuto su Google e, a giudicare dalla mole di risultati che ne escono fuori, sembra un problema capitato a tanti altri.

Questo problema si è presentato in questi giorni in un blog (che non amministro) e, chiaramente, il primo consiglio che si dà in questi casi è quello di disabilitare tutti i plugin, mettere il tema standard di WordPress (oggi TwentyTen, domani sarà TwentyEleven) e forzare l’aggiornamento della cache di FeedBurner (se si usa questo servizio). Nonostante questi passaggi, il problema persiste. Consiglio, quindi, di aggiornare a WordPress 3.1.2, visto che vengo anche a sapere che la versione in uso era la 3.1.1, ma niente da fare. Ottenuto l’accesso via FTP, decido di procedere a un aggiornamento manuale. Mentre osservavo l’upload dei file, lo sguardo mi cade sul file wp-config.php che — ovviamente — viene saltato nell’aggiornamento e mi domando:

E se fosse lui, il problema?

Intuizione corretta! Finito l’upload di tutti i file del core, compresi quelli del tema TwentyTen, e constatato che neanche questa soluzione era efficace, mi butto sul file in questione. Con un piacere quasi sadico mi accorgo che il file si chiudeva in questo modo:

?>
// riga vuota
// riga vuota

cioè con il tag di chiusura di PHP 1 più due righe vuote alla fine del file. Elimino il tag di chiusura del file: le righe vuote alla fine del file non mi interessano più, una volta che quel tag è stato eliminato e uploado il file corretto.

Magia!

Bonus extra. Dai uno sguardo al tuo file wp-config.php che magari ti porti dietro da anni e accertati che le righe delle chiavi di sicurezza siano 8. Se non sono 8, prelevale dal WordPress.org secret-key service e sostituisci quelle che hai in quel file. Per entrare, poi, in bacheca dovrai autenticarti nuovamente.

Note

  1. Tra l’altro, mi chiedo, perché in WordPress è così onnipresente questo tag di chiusura?