Aldolat.it — Post con tag Permalink

Cambiare la guid dei post

aldolat@gmail.com (Aldo Latino) — Wed, 19 May 2010 10:37:34 +0000

In uno dei siti che gestisco e realizzati con WordPress, avevo l’esigenza di cambiare la GUID di ogni post in modo che combaciasse con il suo ID o, per essere più chiari, con il permalink di default (tipo http://miosito.it/?p=123). Il motivo per cui non combaciava era dovuto all’importazione da un file XML estraneo a WordPress. L’operazione di sostituzione può essere effettuata con gli strumenti che il CMS ci fornisce e, visto che magari vi può tornare utile, questo è lo script che ho usato:

 1<?php
 2global $wpdb, $post;
 3$myposts = get_posts('numberposts=-1');
 4$i = 0;
 5$updated = 0;
 6$not_updated = 0;
 7foreach($myposts as $post) :
 8    setup_postdata($post);
 9    $i++;
10    $current_guid = get_post_field('guid', $post->ID);
11    $correct_guid = get_permalink($post->ID);
12    if ($current_guid != $correct_guid) {
13        $where = array('ID' => $post->ID);
14        $wpdb->update($wpdb->posts, array('guid' => $correct_guid), $where);
15        echo $i.'. GUID del post '.$post->ID.' aggiornato da '.$current_guid.' a '.$correct_guid.'<br />';
16        $updated++;
17    } else {
18        echo $i.'. GUID del post '.$post->ID.' OK<br />';
19        $not_updated++;
20    }
21endforeach;
22  
23echo '<p><strong>Risultato:</strong><br />';
24echo 'Righe aggiornate: <strong>'.$updated.'</strong><br />';
25echo 'Righe non aggiornate: <strong>'.$not_updated.'</strong><br />';
26echo 'Totale righe controllate: <strong>'.($updated+$not_updated).'</strong></p>';
27?>

In poche parole, lo script confronta il campo guid della riga del post con il permalink (che, anche temporaneamente, va impostato come “Default”) e, se è diverso, lo adegua. Alla fine dell’operazione, lo script stampa tutte le operazioni eseguite, sia che abbia modificato la riga del database sia che non lo abbia fatto.

Ho utilizzato lo script incollandolo nell’index.php, subito dopo la chiamata all’header. In pochi secondi tutte le migliaia di post avevano la GUID corretta. Per averne anche un riscontro visivo, si può aggiungere all’interno del loop, magari proprio prima del titolo del post, questa riga:

echo get_post_field('guid', $post->ID).'<br />'.get_permalink( $post->ID );

Nel Codex, alla pagina Interfacing With the Database ci sono tutte le informazioni necessarie, in particolare il paragrafo “UPDATE rows”.

L'articolo Cambiare la guid dei post è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Occhio al costrutto per i Canonical URLs

aldolat@gmail.com (Aldo Latino) — Wed, 25 Mar 2009 13:55:58 +0000

Nel precedente articolo sui Canonical URLs avevo commesso un errore di distrazione. Succede. 🙂 Avevo inserito questa sintassi:

<link rel="canonical" content="http://www.miosito.it/2006/miopost/" />

ma è sbagliata, appunto perché <link> non è un meta-tag, ma un link-tag, proprio come i link ai file CSS. Ecco, quindi, la corretta sintassi, come anche riporta la pagina di Google che vi linkavo:

<link rel="canonical" href="http://www.miosito.it/2006/miopost/" />

Per cui il codice PHP da inserire nell’<head> è il seguente:

<?php
global $wp_query;
if (is_single() || is_page()) {
  echo '<link rel="canonical" href="' . get_permalink($wp_query->post->ID) . '" />';
}
?>

Scusate l’errore. Me ne sono accorto grazie a un messaggio inviato su Twitter da Franz Enzenhofer.

L'articolo Occhio al costrutto per i Canonical URLs è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Ottimizzare i link per Google: i Canonical URLs

aldolat@gmail.com (Aldo Latino) — Fri, 06 Mar 2009 14:17:31 +0000

Nota

Dalla versione 2.9 di WordPress questa funzione è implementata nel core, per cui non è più necessario aggiungerla.

Cosa sono i “Canonical URLs”? Una rapida occhiata alla pagina di Wikipedia e in particolare al paragrafo Normalization_process ci dovrebbe illuminare abbastanza, tanto da farci prendere le dovute precauzioni. 🙂 In poche parole si tratta di questo: una data pagina potrebbe essere raggiungibile attraverso distinti indirizzi, ad esempio:

https://www.aldolat.it/miopost/
https://www.aldolat.it/miopost/comment-page-1/
https://www.aldolat.it/miopost/comment-page-2/

ecc., e tutti con o senza trailing slash (/), con tutte le lettere maiuscole e minuscole, ecc. Tutto questo comporta che lo stesso identico articolo possa comparire nei motori di ricerca sotto diversi indirizzi. Google ci dà la possibilità di definire quale sia una volta per tutte l’indirizzo che preferiamo per ogni pagina/post creato utilizzando il tag <link> all’interno del tag <head> di ogni pagina. Lo possiamo fare in modo semplice modificando il file del nostro tema.

Dal backend di WordPress modificate il file header.php del tema in uso e subito prima del tag di chiusura </head> inserite queste righe:

<?php global $wp_query;
  if (is_single() || is_page()) {
    echo '<link rel="canonical" href="' . get_permalink($wp_query->post->ID) . '" />';
  } ?>

Salvate il file, aprite una pagina statica o un post e osservate il codice generato (da Firefox CTRL+U); scorrete le righe fino al tag </head> e accertatevi che vi sia l’output corretto del codice inserito prima, vale a dire una riga del tipo:

<link rel="canonical" href="http://www.miosito.it/2006/miopost/" />

Con estrema semplicità adesso Google saprà che tutti i duplicati fanno riferimento a un link “canonico”. Nel link all’Official Google Webmaster Central Blog trovate anche una serie di FAQ interessanti.

[EDIT]
Si intende che potrete vedere il codice HTML generato dalle righe di PHP solo nelle pagine singole degli articoli o in quelle statiche (com’è giusto che sia: sono quelle le pagine che hanno il link “canonico” o “sorgente”). Non l’avevo fatto notare a modo nel post.

L'articolo Ottimizzare i link per Google: i Canonical URLs è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Impostare in maniera efficiente i permalink

aldolat@gmail.com (Aldo Latino) — Fri, 06 Mar 2009 10:41:33 +0000

Avvertenza

La gestione dei permalink è stata notevolmente migliorata a partire da WordPress 3.3, per cui queste informazioni risultano obsolete. In termini assoluti, avere un valore numerico in testa al permalink dà prestazioni migliori; ma in termini pratici le differenze di performance tra l’avere un valore numerico e non averlo sono irrisorie se non addirittura inesistenti. Per informazioni dettagliate su come funzionano i permalink in WordPress 3.3 e versioni successive è utile il post di Otto.

Circa un mese fa è nata una interessante discussione nel forum di WordPress relativa a un elevato e insolito numero di query al database (più di 2.000) ogni volta che si apriva una pagina di un determinato sito. La discussione si è portata avanti tra segnalazione nel Trac di WordPress, discussione in mailing-list e aggiunte al Codex, nonché su blog importanti come quello di Dougal Campbell (da cui questo articolo trae spunto). Credo sia utile far conoscere quanto si è discusso per nostra informazione e annotazione.

Il problema

Un utente di WordPress lamentava, come già detto, un elevato numero di query per ogni pagina aperta del suo sito, causando un rallentamento eccessivo; la navigazione era possibile, ma in modo molto lento e fastidioso. Su questo sito, che contava tantissime pagine e con svariati allegati, aveva tentato di tutto, disattivando qualsiasi plugin, rimettendo il tema standard e provando addirittura un hosting diverso (in locale). Il risultato fu che le query continuavano ad essere sempre le stesse. L’utente aprì quindi una discussione sul forum e, dopo qualche scambio di informazioni, si giunse alla conclusione che il problema era dovuto alla sua struttura dei permalink. Questa era del tipo /%category%/%year%/%monthnum%/%day%/%postname%/.

Come WordPress preleva gli articoli

Come sapete, WordPress è molto flessibile nella gestione dei permalink: fornisce all’utente la possibilità di poterla impostare come vuole lui, secondo i suoi gusti e le sue esigenze: %year%, %monthnum%, %day%, %hour%, %minute%, %second%, %postname%, %post_id%, %category%, %tag%, e %author%, combinandoli come meglio crede.

Per blog e siti di piccole dimensioni, una impostazione non proprio efficiente dei permalink non causa alcun problema di navigazione e, per restare nel problema al centro dell’articolo, non causa alcun rallentamento. Ma quando si ha davanti un sito con moltissime pagine statiche (intendo le pagine staccate rispetto al flusso temporale degli articoli), con tantissimi allegati, tantissimi post (quindi un sito molto “grande”) e una struttura dei permalink del tipo /%category%/%postname%/ oppure anche solo /%postname%/, allora il discorso cambia radicalmente. WordPress, infatti, davanti a questo materiale e con questi permalink fatica a trovare quello che si vuole. Vediamo perché. Per spiegarlo utilizzo lo stesso esempio che Otto ha usato nella discussione in mailing-list (metto in blockquote il testo, ma è una mia interpretazione libera del suo testo e non una traduzione).

Consideriamo un permalink del tipo /%category%/%postname%/. Un visitatore arriva nel blog cercando la pagina “mycat/mypost/”. Per noi è immediatamente comprensibile di cosa si tratta, ma non per WordPress, il quale inizia ad analizzare queste due voci.

Inizia con “mycat” e indaga su cosa sia. Dapprima si accerta se sia una pagina ed interroga il database: esiste nella tabella “wp_posts” un “post_slug” che ha “mycat” con “post_type” uguale a “page” (select from wp_posts where post_slug = mycat and post_type = page)? No, non esiste.

Quindi, tenta di vedere se “mycat” è una categoria. Esiste in “wp_terms” e (join) “wp_term_taxonomy” qualcosa in cui “term” è “mycat” e “taxonomy” è “category” (select from wp_terms join wp_term_taxonomy on (term_id = term_id) where term = mycat and taxonomy = category)? Si esiste. Ottimo, ma c’è un problema: è solo una categoria, non è il post che stiamo cercando. Passiamo oltre e ignoriamo la categoria.

WordPress lascia perdere, quindi, “mycat” e passa a “mypost”. E ricomincia la tiritera delle interrogazioni.

È una pagina (select from wp_posts where post_slug = mypost and post_type = page)? No.

È una categoria (select from wp_terms join wp_term_taxonomy on (term_id = term_id) where term = mypost and taxonomy = category)? No.

È un post (select from wp_posts where post_slug = mypost and post_type = post)? Sì. Bingo!

Da questo si capisce quanto le categorie (ad inizio permalink) non aiutino a determinare la natura di ciò che si sta cercando. Sono state eseguite ben cinque query (delle quali due molto dispendiose, join) solo per capire quale sia il post. E ciò avviene ogni volta che si vuole visualizzare un post sul vostro sito.

Otto, in risposta al thread Wordpress scaling problems, 29 gennaio 2009.

Immaginiamo, quindi, cosa succede quando un sito sia molto esteso e abbia tantissime visite ogni secondo. Per questo motivo WordPress, per evitare tali problemi quando rileva che la nostra struttura dei permalink non è efficiente, genera delle regole di reindirizzamento (rewrite_url) per ogni cosa scriviate (post, pagina, attachment), cui ricorre ogni volta che viene richiesta una pagina del sito (che sia un post o altro). Queste regole di reindirizzamento, però, crescono a dismisura quando il sito è enorme, quando ci sono tantissime pagine statiche e relativi attachment (era il caso dell’utente di poco fa). Questa tabella può crescere così tanto da causare problemi alla navigazione.

Come impostare nel modo più efficiente i permalink

Qual è, allora, la migliore impostazione dei permalink?

Se “migliore” lo intendiamo in termini di efficienza, senza dubbio essa consiste nell’usare come primo elemento del permalink un valore numerico (%year%, %monthnum%, %day%, %hour%, %minute%, %second% e %post_id%) o addirittura la struttuta standard miosito.com/?p=123 (che presenta altre problematiche, ma non in termini di efficienza). I problemi sorgono quando si mette come primo elemento un valore testuale come %postname%, %category%, %tag%, e %author%: in questo caso WordPress o esegue tutta quella tiritera o deve impostarsi delle regole di reindirizzamento: entrambi i sistemi sono comunque dispendiosi in termini di risorse.

Se il vostro sito/blog rientra nelle caratteristiche dette prima, rivedete i vostri permalink. Se avete un piccolo blog non preoccupatevi di nulla e usate pure la struttura che più vi piace.

Anche nel Codex è stato inserito, dopo la discussione in mailing-list, questo avviso:

For performance reasons, it is not a good idea to start your permalink structure with the category, tag, author, or postname fields. The reason is that these are text fields, and using them at the beginning of your permalink structure it takes more time for WordPress to distinguish your Post URLs from Page URLs (which always use the text “page slug” as the URL), and to compensate, WordPress stores a lot of extra information in its database (so much that sites with lots of Pages have experienced difficulties). So, it is best to start your permalink structure with a numeric field, such as the year or post ID. See wp-testers discussion of this topic.

La situazione di questo blog

Ubuntu block notes ha adottato per molto tempo la struttura /%category%/%postname%/, perché la ritengo ottima da punto di vista “umano”: si capisce subito sotto quale categoria si trova quell’articolo. Ma per i motivi su esposti ho cambiato la struttura utilizzandone una molto simile: /%year%/%category%/%postname%/, inserendo quindi un valore numerico all’inizio.

La differenza di peso dei due file contenenti le regole, prima e dopo la “cura”.

Prima di effettuare il cambio, però, ho dato un’occhiata al database per vedere cosa avessi nella tabella wp-options > rewrite_rules. Stentavo a crederci: quasi 2.000 linee di regole! Dopo il cambio dei permalink, ho rivisitato la tabella e le righe sono scese a 200, cioè un decimo! E pensare che questo blog è piccolo: attualmente 310 articoli, 26 pagine, 12 categorie e 361 tag (ma non so quanti attachment). È evidente che WordPress ringrazia e con lui il server su cui gira.

Per approfondire date un’occhiata anche agli interessanti commenti all’articolo di Dougal, dove gli utenti pongono domande su dubbi che probabilmente potranno sorgere a chi ha letto quest’articolo.

Update

Ho preparato un diagramma di flusso per capire quando è il momento di cambiare la struttura dei permalink con una più efficiente:

Fare clic per ingrandire

L'articolo Impostare in maniera efficiente i permalink è uno scritto di aldolat.it. Rispettane le condizioni di licenza.