Il nuovo paragrafo di Inerario (§ 31) è dedicato al modo di impostare la pagina-genitore di default per tutte le nuove pagine del sito create e pubblicate con il WordPress.
Il paragrafo è stato pensato per gli sviluppatori backend e per gli utenti avanzati del WordPress.
https://www.eugigufo.net/it/inerario/paragrafo31/
Il nuovo paragrafo di Inerario (§ 30) è dedicato al modo di realizzare un blog su una pagina diversa dalla pagina iniziale di un sito creato con il WordPress.
Il paragrafo è stato pensato per gli sviluppatori web, ma sarà utile anche per i semplici proprietari dei siti web.
https://www.eugigufo.net/it/inerario/paragrafo30/
Il nuovo paragrafo di Inerario (§ 28) è dedicato al modo di realizzare un menu breadcrumbs totalmente automatizzato e personalizzabile per i siti costruiti con il WordPress. La soluzione proposta nel paragrafo è una funzione in PHP che si adatta ugualmente bene ai siti di qualsiasi complessità strutturale e di qualsiasi grandezza.
Il paragrafo dovrebbe essere utile e interessante prevalentemente agli sviluppatori backend e frontend, ma anche alle persone che si occupano personalmente dei propri siti.
http://www.eugigufo.net/it/inerario/paragrafo28/
Il nuovo paragrafo di Inerario (§ 23) è dedicato ai modi possibili di disabilitare (o limitare dal punto di vista quantitativo) il salvataggio delle revisioni dei testi pubblicati sui siti basati si WordPress.
Si tratta delle operazioni utili al contenimento della crescita sproporzionata di dati contenuti nel database di un sito. Perché i database costano, ma servono. Mentre i database «gonfi» rallentano il sito. Di conseguenza, il contenuto del paragrafo sarà utile a tutti i proprietari e/o amministratori dei siti basati su WordPress.
http://www.eugigufo.net/it/inerario/paragrafo23/
Il nuovo paragrafo di Inerario (§ 22) è dedicato alla pulizia e ottimizzazione dei database dei siti basati su WordPress.
Si tratta delle semplici istruzioni pratiche comprensibili non solo ai programmatori, ma anche ai «semplici» proprietari e/o amministratori dei siti web. Nel paragrafo si dimostra che chiunque è in grado di migliorare le prestazioni di un sito in pochissimo tempo e con il minimo sforzo.
http://www.eugigufo.net/it/inerario/paragrafo22/
Supponiamo di voler utilizzare sul nostro sito i meta tag robots. Il loro inserimento nei codici delle singole pagine sarebbe stato una operazione semplicissima, ma i siti moderni sono ormai tutti (o quasi) fatti con i CMS: con il codice comune a tutte le pagine (o a dei grossi insiemi di esse). I parametri dei meta tag robots da noi voluti, però, potrebbero variare da pagina a pagina. La soluzione esiste ed è abbastanza semplice.
Prima di tutto rifiutiamo l’idea di creare una molteplicità delle pagine header.php solo per metterci i meta tag diversi: associare i header ai rispettivi contenuti e aggiornarli in base alle necessità mutate è un lavoro troppo impegnativo che tende ad azzerare i vantaggi dell’utilizzare un tema. E noi siamo pigri.
Di conseguenza, dobbiamo ragionare in modo strutturato e immaginare prima di tutto i casi in cui potrebbero variare i parametri dei meta tag robots.
1. I meta tag robots per le pagine-doppioni
Come ho già accennato nel paragrafo dedicato alla costruzione di un file robots.txt corretto, i CMS generano una grande quantità delle pagine almeno in parte coincidenti tra loro nei contenuti. Quindi noi dobbiamo prima di tutto vietare l’indicizzazione di tutte le pagine-doppioni. Tali pagine sono generate dalle seguenti funzioni:
– la funzione che mostra i contenuti delle categorie;
– la funzione che mostra ogni genere di archivio;
– la funzione che mostra gli archivi per anni;
– la funzione che mostra gli archivi per mesi;
– la funzione che mostra gli archivi per giorni;
– la funzione che mostra gli archivi per date;
– la funzione che mostra gli archivi per autori;
– la funzione che mostra le pagine con i tag;
– la funzione che mostra la tassonomia delle pagine casuali;
– la funzione che mostra le pagine con dei file allegati;
– la funzione che mostra il menu di navigazione tra le pagine in sequenza;
– la funzione che mostra le pagine dei feed;
– la funzione che mostra le pagine dei risultati delle ricerche interne al sito.
Ecco, il nostro compito consiste nell’inserire i meta tag robots con i parametri di diniego noindex e nofollow nei codici delle pagine dell’elenco sovrastante tra i tag <head> e </head>.
Lo possiamo fare con una funzione inserita nel file functions.php subito sotto il tag di apertura <?php.
Ecco il suo codice:
Viva l’Ucraina! No alla guerra!
RSS del blog
function pagdoppie_robots () {
if (is_archive() or is_category() or is_feed () or is_author() or is_date() or is_day() or is_month() or is_year() or is_tag() or is_tax() or is_attachment() or is_paged() or is_search())
{
echo "".'<meta name="robots" content="noindex,nofollow" />'."\n";
}
}
add_action('wp_head', 'pagdoppie_robots');
In sostanza, questa funzione contiene una condizione che «scatterà» con l’avvio di ognuna delle funzioni elencate e tramite il comando echo aggiungerà il meta tag robots nel codice delle pagine-doppioni. Poi, con l’aiuto dell’action hook wp_head la nostra azione verrà automaticamente attaccata alla funzione wp_head(), la quale, a sua volta, inserirà il meta tag nel header tra i tag <head> e </head>.
Ebbene, è tutto qui. Dopo un tempo relativamente breve, entro un paio di giorni, le pagine-doppioni scompariranno dai risultati di ricerca di Google e altri «motori». E vi resteranno solo quelle sensate e originali, raccogliendo dunque più visite di prima.
2. I meta tag robots per le pagine determinate
Ora ipotizziamo di voler utilizzare i meta tag robots solo per alcune singole pagine del sito, quelle contenenti i testi originali. Non importa se le abbiamo create attraverso la voce «pagina» o «articolo» delmenu di WordPress: il loro codice sorgente è in ogni caso molto simile a tutte le altre.
Di conseguenza, anche in questo caso dobbiamo scrive una funzione da inserire nel file functions.php del nostro tema. L’unica differenza di questa funzione dalla precedente è l’utilizzo della funzione «is_page» con l’elenco degli ID delle pagine alle quali vogliamo applicare i meta tag robots:
function pagalcune_robots () {
if ((is_page(array(11, 222, 345))))
{
echo "".'<meta name="robots" content="noindex,nofollow" />'."\n";
}
}
add_action('wp_head', 'pagalcune_robots');
Ovviamente, al posto dei numeri utilizzati nel mio esempio («11», «222» etc) dovete inserire gli ID corretti delle vostre pagine.
Non sapete come scoprire l’ID di una pagina? È semplicissimo. Andate sulla admin di WordPress del vostro sito, entrate nella sezione «articoli» o «pagine» (in base alla modalità con la quale avete pubblicato la pagina) e posizionate il cursore sopra il nome della pagina alla quale volete applicare i meta tag. L’unico numero che vedrete nell’indirizzo comparso in basso è l’ID della pagina (sì, proprio quello dopo la dicitura ?post=).
Qualora si volesse applicare i meta tag robots a una sola pagina (invece che a più pagine), il codice della funzione sarà ancora più semplice:
function pagina_robots () {
if ((is_page('123')))
{
echo "".'<meta name="robots" content="noindex,nofollow" />'."\n";
}
}
add_action('wp_head', 'pagina_robots');
Ovviamente anche in questo caso non dovete dimenticare di inserire l’ID corretto al posto di «123».
E pure questo caso è da considerare risolto.
P.S. Naturalmente, le operazioni descritte in questo paragrafo non sono necessarie qualora volessimo negare l’indicizzazione dell’intero sito. In quest’ultimo caso, infatti, è sufficiente inserire nel codice della pagina header.php questa riga:
<meta name="robots" content="noindex, nofollow" />
Come ben sanno molti di voi, un file robots.txt di qualità ha una notevole importanza per la popolarità della maggioranza dei siti web. Nel paragrafo precedente abbiamo visto i principi generali per la creazione di un buon robots.txt.
Molti di voi sanno però altrettanto bene che un sito web basato su un CMS ci aggiunge delle difficoltà in più nella creazione del robots.txt realmente efficiente. Le difficoltà consistono nel dover vietare l’indicizzazione di una molteplicità di pagine generate automaticamente dal CMS (nel nostro specifico caso il WordPress) che ripetono i contenuti delle pagine originali create dagli amministratori del sito. Si tratta quindi delle pagine-doppioni sulle quali i contenuti vengono richiamati e visualizzati perché selezionati per categoria, tag, data, anno, mese etc. Eliminando tutti i doppioni dai risultati di ricerca sui «motori» (Google e altri) facciamo aumentare l’affidabilità del sito e la quantità delle visite alle sue pagine originali.
Inoltre, per motivi di sicurezza conviene eliminare dai risultati di ricerca tutte le pagine che riguardano l’amministrazione del nostro sito.
Vediamo subito un esempio pratico di un file robots.txt scritto appositamente per un sito costruito su WordPress. Ecco il suo testo minimo indispensabile (l’unica cosa che dovrete necessariamente cambiare è l’indirizzo del sito all’ultima riga):
User-agent: * # la direttiva per i robots diversi da quelli di Google e Yandex Disallow: /cgi-bin # una directory del vostro spazio web Disallow: /? # tutti i parametri della ricerca sulla home Disallow: /wp- # tutti i file di WP: /wp-json/, /wp-includes, /wp-content/plugins Disallow: /wp/ # nel caso della eventuale esistenza del sottocatalogo /wp/ dove e installata la CMS Disallow: *?s= # ricerca Disallow: *&s= # ricerca Disallow: /search/ # risultati ricerca Disallow: /author/ # archivio autori Disallow: /users/ # archivio autori Disallow: */trackback # tutti i trackback nei commenti Disallow: */feed # tutti i feed Disallow: */rss # i feed via rss Disallow: */embed # tutti gli elementi incorporati Disallow: */wlwmanifest.xml # il file xml del Windows Live Writer (se non lo utilizzate, eliminate la direttiva) Disallow: /xmlrpc.php # il file WordPress API Disallow: *utm= # i link con i parametri utm Disallow: *openstat= # i link con i parametri openstat Allow: */uploads # la directory con i file uploads User-agent: GoogleBot # la direttiva per Google (evito di ripetere i commenti identici) Disallow: /cgi-bin Disallow: /? Disallow: /wp- Disallow: /wp/ Disallow: *?s= Disallow: *&s= Disallow: /search/ Disallow: /author/ Disallow: /users/ Disallow: */trackback Disallow: */feed Disallow: */rss Disallow: */embed Disallow: */wlwmanifest.xml Disallow: /xmlrpc.php Disallow: *utm= Disallow: *openstat= Allow: */uploads Allow: /*/*.js # gli script js dentro alla /wp- (/*/ — per la priorita) Allow: /*/*.css # i file css dentro alla /wp- (/*/ — per la priorita) Allow: /wp-*.png # le immagini nei plugin, cartella cache etc Allow: /wp-*.jpg # le immagini nei plugin, cartella cache etc Allow: /wp-*.jpeg # le immagini nei plugin, cartella cache etc Allow: /wp-*.gif # le immagini nei plugin, cartella cache etc Allow: /wp-admin/admin-ajax.php # utilizzata dai plugin per non bloccare JS e CSS User-agent: Yandex # la direttiva per Yandex.ru (non ripeto i commenti in quanto sarebbero uguali ai precedenti) Disallow: /cgi-bin Disallow: /? Disallow: /wp- Disallow: /wp/ Disallow: *?s= Disallow: *&s= Disallow: /search/ Disallow: /author/ Disallow: /users/ Disallow: */trackback Disallow: */feed Disallow: */rss Disallow: */embed Disallow: */wlwmanifest.xml Disallow: /xmlrpc.php Allow: */uploads Allow: /*/*.js Allow: /*/*.css Allow: /wp-*.png Allow: /wp-*.jpg Allow: /wp-*.jpeg Allow: /wp-*.gif Allow: /wp-admin/admin-ajax.php # Non dimenticatevi di indicare il file Sitemap (senza indicarlo per ogni User-agent Sitemap: http://nomesito.it/sitemap.xml
Come potete vedere, il significato di ogni direttiva è spiegato dal relativo commento (come ben sapete, nei file robots.txt i commenti iniziano con il simbolo #).
Alla fine della lista di istruzioni per ogni User-agent potete eventualmente aggiungere tutte le direttive che ritenete necessarie secondo le vostre esigenze. Infatti, una volta dichiarate tutte le istruzioni rese necessarie dalle particolarità tecniche del WordPress, si passa a stabilire le regole — questa volta sulla indicizzazione o non delle pagine del sito — di carattere più ampio già descritte nel paragrafo precedente.
Inoltre, come ho già scritto, è consigliato non far indicizzare le pagine-doppioni, quali gli archivi (creati secondo vari possibili criteri) e i raggruppamenti per categorie e tag. A tal fine dobbiamo aggiungere nell’esempio appena riportato le seguenti righe:
Disallow: /tag # le pagine dei tag Disallow: /category # le pagine delle categorie Disallow: /archive # lepagine degli archivi
Potete metterle in ogni blocco User-agent dopo la riga Disallow: /users/
A questo punto mi restano da aggiungere solo tre precisazioni:
1. Il percorso della mappa del sito (Sitemap) va indicato solo una volta in tutto il file robots.txt.
2. A causa della evoluzione dei meccanismi di Google e altri «motori» di ricerca, non ha più senso vietare l’indicizzazione delle cartelle wp-content, cache, plugins e themes. Ma anche se lo fate, non succede nulla di grave.
3. Evitate di inventare delle regole particolari troppo strane. Per esempio, la direttiva Disallow: /10 nasconderà non solo i vari archivi con le date, ma anche gli articoli con i nomi del tipo «10 consigli su come conquistare le ragazze cinesi» (se l’URL è stato generato dal nome dell’articolo).
Ecco, ora penso di avervi fornito tutte le informazioni essenziali.
P.S.: ovviamente, il file robots.txt deve essere caricato nella root.
So che il sentirsi un genio è abbastanza controproducente nel lungo periodo, ma sono appena riuscito a reimpostare il crossposting automatico da WordPress a Facebook.
Sono riuscito a farlo nonostante una nuova politica del Facebook verso la propria API e la conseguente comparsa di innumerevoli errori incomprensibili (sì, secondo me gli sviluppatori del Facebook programmano con il culo).
Sono riuscito a farlo nonostante essere da poco passato verso il HTTPS.
Sono riuscito a farlo dopo aver letto dieci mila forum dedicati all’argomento, scritto e riscritto mille soluzioni in cinque linguaggi diversi, pensato e pronunciato due milioni di bestemmie e, infine, dopo avere quasi picchiato il computer per disperazione.
Non so ancora se riuscirei a spiegare in modo lineare come – troppi tentativi mescolati in testa – ma sono riuscito a farlo.
Ma vorrei tranquillizzare i colleghi blogger, programmatori e altri: il dialogo tra WP e FB è ancora possibile. Non disperatevi e continuate a lavorarci su.
Nel presente articolo vi spiego come si fa a inserire i banner pubblicitari tra un post e l’altro pubblicati sulla piattaforma WordPress. In realtà è molto semplice.
Supponiamo di voler visualizzare la pubblicità sulla pagina index.php (anche se lo stesso metodo è utilizzabile su qualsiasi pagina del vostro tema destinata alla visualizzazione di più di un post – per esempio le pagine di archivio).
Il metodo № 1. Solo un banner per pagina
Supponiamo ora di non voler annoiare troppo i visitatori del nostro sito con una quantità esagerata di banner. Vogliamo dunque averne solo uno per pagina.
Prima di tutto, cerchiamo nel codice della pagina l’inizio del ciclo dei post. Può essere scritto in questo modo:
<? if (have_posts()) : ?> <? while (have_posts()) : the_post(); ?>
Oppure tutto su una riga: non importa. In ogni caso, prima di tale ciclo inseriamo questo codice:
<?php $counter = 0; ?>
Ora andiamo verso la fine del codice della pagina sulla quale stiamo lavorando e cerchiamo questa riga:
<?php endwhile; ?>
Prima di tale riga inseriamo queste cinque righe di codice:
<?php
$postcount++;
if($postcount==1){?>
<div>// il codice della pubblicita</div>
<?php } ?>
Guardate alla riga 3 del codice appena riportato. Il numero «1» è il numero periodico del post dopo il quale verrà visualizzato il banner pubblicitario. Tale numero può essere cambiato a vostro piacimento (ma, ovviamente, non può essere più alto della quantità massima dei post per pagina che avete indicato nelle impostazioni di WordPress).
Alla riga 4 tra i tag <div> e </div> va inserito il codice del banner pubblicitario.
Abbiamo già fatto tutto!
Il metodo № 2. Più di un banner per pagina
Supponiamo di essere disposti a inserire più di un banner pubblicitario tra gli articoli della stessa pagina.
L’inizio è analogo a quanto scritto per il metodo № 1. Quindi cerchiamo nel codice della pagina queste due righe (oppure riga unica):
<? if (have_posts()) : ?> <? while (have_posts()) : the_post(); ?>
Prima di esse inseriamo questa:
<?php $counter = 0; ?>
Invece dopo sempre quelle due righe inseriamo questa:
<?php $counter = $counter + 1;?>
Per rassicurarvi riporto l’intero blocco del codice che dovrebbe esservi venuto:
<?php $counter = 0; ?> <?php if (have_posts()) : ?><?php while (have_posts()) : the_post(); ?> <?php $counter = $counter + 1;?>
Ora andiamo verso la fine del codice della pagina sulla quale stiamo lavorando e cerchiamo questa riga:
<?php endwhile; ?>
Prima di essa va inserito questo codice di sei righe:
<?php if(1 == $counter) : { ?>
// il codice della prima pubblicita
<?php } endif; ?>
<?php if(3 == $counter) : { ?>
// il codice della seconda pubblicita
<?php } endif; ?>
I numeri 1 e 3 che vedete alle righe 1 e 5 indicano i numeri periodici dei post dopo i quali verranno visualizzati i banner pubblicitari (quindi dopo il primo e dopo il terzo post della pagina). Ovviamente potete cambiare quei numeri a vostro piacimento.
Volete aumentare la quantità dei banner ancora di uno? Nessun problema! Dopo l’ultimo dei codici che vi ho indicato inserite questo:
<?php if(4 == $counter) : { ?>
// il codice della terza pubblicita
<?php } endif; ?>
Potete ripetere quest’ultima una infinità di volte. Ma non esagerate: troppa pubblicità fa scappare i visitatori.
Anzi, i visitatori disturbati dalla troppa pubblicità potrebbero anche decidere di non visualizzarla più sul vostro sito e voi, di conseguenza, non guadagnate nulla.
Oggi scrivo di un problema molto più ricorrente di quanto si possa pensare.
Il problema
Supponiamo di voler installare due WordPress sullo stesso dominio: il primo nella root (sito.it) e il secondo in una cartella (sito.it/cartella). Il risultato che attendiamo è il seguente:
Naturalmente, non sorge alcun problema qualora decidessimo di installare solo una copia di WordPress oppure installarne due o più nelle cartelle dello stesso livello (per esempio, sito.it/cartella1, sito.it/cartella2 etc.). Installando invece i due WordPress nella root e nella cartella, ci troviamo di fronte al non-funzionamento del secondo: al tentativo di aprire qualsiasi pagina appartenente a sito.it/cartella esce l’errore 404.
Le soluzioni
Qualora il nostro server avesse il sistema operativo Linux, avremmo potuto limitarci a inserire nella cartella sito.it/cartella (dove sta il nostro WordPress № 2) un file .htaccess come questo:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
… permettendo in questo modo di convivere pacificamente a sito.it con sito.it/cartella
Su un server Windows, invece, non è possibile utilizzare il file .htaccess Di conseguenza, dobbiamo convertirlo in un file web.config Esistono alcuni strumenti online e offline che permettono di effettuare la conversione in automatico, ma tutti essi hanno lo stesso problema: non sanno convertire il comando RewriteBase (il quale è fondamentale per evitare la comparsa dell’errore 404 al posto di tutte le pagine del WordPress installato nella cartella). Sostituiscono semplicemente quel comando con una riga di commento, senza avvisarci che in questo modo l’intero file diventa non funzionante.
Io, dunque, sono giunto alla seguente soluzione.
Creiamo due file web.config. Il primo, quello più semplice, lo mettiamo nella root dove è installato il WordPress № 1. Ecco il suo codice:
<?xml version="1.0" encoding="UTF-8"?>
<!--Questo file sta nella cartella della root.-->
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="nomeregolaroot" patternSyntax="Wildcard">
<match url="*"/>
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
</conditions>
<action type="Rewrite" url="index.php"/>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Il secondo file web.config è invece più complesso e va caricato nella cartella dove è installato il WordPress № 2. Eccolo:
<?xml version="1.0" encoding="UTF-8"?>
<!--Questo file sta nella cartella caricata nella root.-->
<configuration>
<system.webServer>
<rewrite>
<rules>
<clear />
<rule name="nomeregola1" stopProcessing="true">
<match url="^index\.php$" ignoreCase="false" />
<action type="None" />
</rule>
<rule name="nomeregola2" stopProcessing="true">
<match url="." ignoreCase="false" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="/cartella/index.php" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Attenzione! Alla riga 18 va indicato il nome della cartella nella quale viene caricato il relativo web.config (naturalmente al posto di «cartella»).
Basta, ora entrambi i WordPress devono funzionare correttamente.
So che in teoria avrei potuto provare a escludere l’eredità delle regole nel web.config-«padre» o inserire un <remove> delle regole ereditate nel web.config-«figlio»… Però io di solito preferisco le soluzioni più semplici che non richiedano delle pratiche mentali autolesive prolungate nel tempo. Sul mio sito (che state leggendo ora) ho utilizzato proprio il metodo appena descritto per fare due versioni linguistiche del sito stesso. Come potete vedere, funziona benissimo.
Se volessimo ora installare altre copie di WordPress in altre cartelle più profonde – per esempio, sito.it/cartella1/cartella2 – ci limitiamo a inserire il secondo web.config in ognuna delle cartelle interessate dalla installazione. Dobbiamo solamente ricordarci di indicare il nome della cartella alla riga 18.
È importantissimo, inoltre, indicare tutta la sequenza delle cartelle per i WordPress installati nelle cartelle «profonde». Supponiamo, per esempio, di avere sempre il costrutto sito.it/cartella1/cartella2 dove sono installati tre copie di WordPress: la prima nella root, la seconda nella cartella1 e la terza nella cartella2. La riga 18 del file web.config caricato nella cartella2 deve essere così:
<?xml version="1.0" encoding="UTF-8"?>
<!--Questo file sta nella in una sottocartella (root/cartella/cartella/).-->
<configuration>
<system.webServer>
<rewrite>
<rules>
<clear />
<rule name="nomeregola1cartella" stopProcessing="true">
<match url="^index\.php$" ignoreCase="false" />
<action type="None" />
</rule>
<rule name="nomeregola2cartella" stopProcessing="true">
<match url="." ignoreCase="false" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="/cartella1/cartella2/index.php" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Il metodo è stato testato con successo dal sottoscritto.
Se avete delle domande o soluzioni alternative, scrivetemi pure!
