Skip to main content

Come aggiungere gli annunci automatici AMP AdSense (e/o altro codice HTML AMP-only) su WordPress

Nelle ultime settimane AdSense Lab, il reparto sperimentale della nota piattaforma di advertising Google AdSense, ha lanciato una nuova funzionalità sperimentale, chiamata Annunci Automatici AMP: si tratta di  una famiglia di formati che consentono di monetizzare in modo nuovo le pagine AMP. Una volta attivati, Google AdSense inserirà automaticamente gli annunci di testo e display all’interno delle pagine AMP sfruttando gli spazi disponibili.

Nel remoto e improbabile caso in cui non abbiate idea di cosa sia una pagina AMP e/o non abbiate mai sentito parlare del progetto AMP, fatevi una cultura dando un’occhiata a questo sito.

La funzionalità è attualmente in beta e disponibile soltanto mediante l’attivazione del servizio AdSense Lab ed ha queste ulteriori caratteristiche:

  • Al momento sono supportati solo gli annunci di testo, display e di ancoraggio.
  • Gli annunci automatici AMP prevedono la pubblicazione di un numero di annunci adeguato alla quantità di contenuti sulla pagina, tenendo conto di eventuali <amp-ad> codificati in forma rigida preesistenti.Gli annunci automatici AMP per il momento verranno visualizzati solo dagli utenti di dispositivi mobili. Accedi al tuo sito da dispositivo mobile per visualizzarne gli annunci automatici AMP.

Per maggiori informazioni è possibile consultare questa pagina dedicata sul sito Google AdSense.

Approfondisci

WordPress – Catchable fatal error: Object of class WP_Error could not be converted to string – Come risolvere

L’11 giugno 2017 questo sito ha subito un downtime di diverse ore a causa di un errore piuttosto strano verificatosi all’interno del database di WordPress. Se vi siete imbattuti in questo articolo è molto probabile che il vostro sito sia stato colpito dalla medesima problematica. Se le cose stanno così, siete finiti nel posto giusto: farò del nostro meglio per aiutarvi a risolvere raccontandovi la mia esperienza.

Dal punto di vista dell’utente, l’anomalia si presentava come un classico errore HTTP 500 – Application Error che bloccava tutte le pagine non servite tramite cache. Come sempre in questi casi la prima cosa che ho fatto è stata abilitare gli appositi switch WP_DEBUG e WP_DEBUG_LOG presenti all’interno del file wp-config.php, che – come probabilmente sanno molti lettori – si trova nella cartella principale di WordPress contiene tutti i parametri di configurazione principali dell’installazione in uso.

Come si può facilmente evincere dai commenti, il primo switch inserisce l’errore all’interno del HTTP response così da consentire all’utente di visualizzarlo on-screen, mentre il secondo – più sicuro – si limita a scriverlo all’interno di un file debug.log dedicato, anch’esso presente nella cartella principale di WordPress.

Questo era l’errore riportato:

Catchable fatal error: Object of class WP_Error could not be converted to string in /var/www/ryadel.com\wp-includes\rewrite.php on line 326

Sfortunatamente questa informazione non era sufficiente a comprendere cosa fosse davvero successo, ma se non altro puntava in una direzione chiara: ho quindi dato un’occhiata al codice sorgente del rewrite.php, fino a imbattermi nella seguente funzione (la linea 326 è quella evidenziata):

Approfondisci

PHP – Come disabilitare la visualizzazione e il log degli errori da codice

Ogni sviluppatore, amministratore di sistema o webmaster che lavori o abbia lavorato con PHP conosce perfettamente che il metodo migliore per effettuare un debug rapido su uno script o pagina realizzata con il popolare Hypertext Preprocessor  è quello di impostare i valori opportuni delle direttive error_reportingdisplay_errors e/o log_errors contenute all’interno del file PHP.INI.

Ecco un tipico esempio di configurazione per un web server di produzione:

Approfondisci

PHP – Come risolvere l’errore “Warning: preg_replace(): The /e modifier is no longer supported” in PHP 7

In questo articolo parleremo di uno dei classici errori che si verificano quando si tenta l’upgrade da PHP5.x a PHP7:

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead

Nonostante il problema in questione sia ben documentato nella documentazione ufficiale di PHP (l’utilizzo del modificatore /e  è deprecato fin dalla release 5.5 e non più supportato dalla 7.0.0 in poi), il warning di cui sopra resta uno dei più complessi da affrontare, principalmente perché non esiste un workaround valido per tutte le situazioni: il modo migliore di procedere è, ovviamente, quello suggerito dalla documentazione: procedere a una re-implementazione del codice, utilizzando la funzione preg_replace_callback in luogo del modificatore /e: sfortunatamente nella maggior parte dei casi non si tratta di un lavoro semplice, perché la funzione preg_replace è presente in numerosissimi script PHP di terze parti che è particolarmente scomodo modificare.

In questo articolo proveremo a documentare tre diversi metodi che sono stati messi a punto dalla community internazionale per risolvere il problema in modo soddisfacente: sentitevi liberi di scegliere quello che meglio si presta al vostro scenario specifico.

Approfondisci

PHP – Come eliminare i caratteri non validi da un file o stringa XML in formato UTF-8

Ieri ho scritto due righe su un metodo PHP per eliminare l’header e il footer di un file XML.P7M firmato elettronicamente (a patto che sia in formato CAdES): piuttosto brutto a vedersi, poco ma sicuro, ma se non altro faceva e fa il suo lavoro.

Oggi verserò un altro tributo alle funzioni “brutte ma (almeno) funzionanti” pubblicando anche la funzione che ho sviluppato a corredo della precedente per ripulire il contenuto del suddetto file da caratteri non validi, così da poter utilizzare la stringa risultante come parametro per la creazione di di un oggetto SimpleXML:

Approfondisci

Close