MENU


Sito segnalato come malicious


A volte purtroppo accade che un sito sia segnalato come malicious. Spesso e volentieri potete aprire l’html lato client side, di una qualsiasi pagina e troverte un iframe che porta ad una pagina esterna che contiene un malaware. A parte il problema di capire come quel codice sia finito li e come evitare che torni è necessario rimuoverlo. Ma se cercherete nel codice sorgente quell’iframe difficilmente lo troverete. Provate invece a cercare “base64_decode” a questo punto probabilmente troverete un paio di righe in cui una stringa che appare come una lunghissima sequenza di caratteri viene decodificata nel codice dell’iframe. Questa è la parte dda rimuovere.
Read More ›


WordPress: aggiornamenti di plugin e temi ( automatici )


Non tutti sanno che è possibile abilitare per wordpress gli aggiornamenti automatici per plugin, temi e core. Bisogna agire sul file functions.php del proprio child themee inserire le seguenti righe di codice: Per abilitare gli aggiornamenti automatici dei plugin, utilizzare quanto segue: add_filter( 'auto_update_plugin', '__return_true' ); Per abilitare gli aggiornamenti automatici dei temi, utilizzare quanto segue: add_filter( 'auto_update_theme', '__return_true' );
Read More ›


Modifica e update degli indirizzi WordPress nel database relativi ad una migrazione


Per un motivo o per l’altro a volte durante una migrazione è più semplice e veloce una procedura completamente manuale per migrare un sito piuttosto che non l’utilizzo dei plugin. Ad esempio per la creazione di un ambiente di test sulla stessa macchina con l’ambiente di sviluppo dalla console di linux con un cp per i file e query dirette sul database la procedura è davvero velocissima. A seguire quindi è necessario eseguire l’update del database perchè wordpress utilizza url assoluti e non relativi. Non ho ancora capito il perchè ma una motivazione valida ci sarà senza dubbio. Per eseguire tutte le update ecco il codice. UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl'; UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl','http://www.newurl'); UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl'); UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://www.oldurl','http://www.newurl');
Read More ›


Sito bloccato: Momentaneamente non disponibile per manutenzione. Riprovare fra un minuto.


Può capitare che dopo un aggiornamento di wordpress il sito rimanga bloccato con la scritta “Momentaneamente non disponibile per manutenzione. Riprovare fra un minuto.” negando l’accesso sia al frontend che al backoffice. Il modo per sbloccarlo è di collegarsi via FTP, nella root troverete un file .maintenance che dovete cancellare. I file che iniziano per . (punto) come .maintenance , .htaccess sono file invisibili per linux per cui ricordatevi di configurare il vostro client FTP per la visualizzazione dei file nascosti.
Read More ›


Cannot modify header information, headers already sent by – caso di pagina bianca su WordPress


Ultimamente sul server che ho acquistato mi sono imbattuto nell’errore di White Screen of Death (pagina del sito bianca), attivato il debug ho verificato questo errore : Warning: Cannot modify header information - headers already sent by (output started at /XXX/wp-config.php:1) in /XXX/wp-login.php on line 425 Warning: Cannot modify header information - headers already sent by (output started at /XXX/wp-config.php:1) in /XXX/wp-login.php on line 438 Warning: Cannot modify header information - headers already sent by (output started at /XXX/wp-config.php:1) in /XXX/pluggable.php on line 925 Warning: Cannot modify header information - headers already sent by (output started at /XXX/wp-config.php:1) in /uXXX/wp-includes/pluggable.php on line 926 Warning: Cannot modify header information - headers already sent by (output started at /XXX/wp-config.php:1) in /XXX/wp-includes/pluggable.php on line 927 l’installazione era perfettamente funzionante su altro server. Il problema è subito chiaro, esiste un redirect che non viene gestito perchè siccome “headers already sent” allora “Cannot modify header information” . Altre casistiche sono: un output già esistente come una linea vuota precedente all’apertura di php un echo una dichiarazione header (tipo “header(‘Content-Type: ‘.get_bloginfo(‘html_type’).’; charset=’.get_bloginfo(‘charset’));” )   Come poter permettere che le “header information” siano modificabili dopo essere già state inviate? L’ideale è poter modificare la variabile output_buffering in […]
Read More ›


WordPress “elemento non aggiornato” tassonomie


Ho trovato uno strano problema con la relativa soluzione. In wp_term_taxonomy abbiamo le nostre tassonomie, quindi categorie, tag e custom taxonomy . Ora se voi create una categoria che si chiama per sempio tecnologia e poi un tag che si chiama tecnologia, nel momento in cui andrete a scrivere o modificare la descrizione della categoria succitata wordpress vi dirà bellamente “Elemento non aggiornato.”. La ragione è dovuta al fatto che sono stati creati due slug identici in wp_term_taxonomy e all’aggiornamento qualcosa va storto. E’ un baco, un baco che secondo ricerche online arriva da molto lontano del tempo. La morale della favola è che se volete fare delle modifiche lato backoffice e non direttamente da mySql dovete necessariamente modificare uno dei due slug.
Read More ›


WordPress e l’abuso di wp_postmeta e la sua pulizia


Se googolate wp_postmeta le prime pagine sono tutte relative alla richiesta di istrusioni per la pulizia di wp_postmeta oppure sulle istruzioni relative alla pulizia della stessa. In effetti altra cosa che non amo di wordpress (apena scritto di cose che non amo di wordpress nell’articolo precedente) è l’ultizzo del database. Dando un’occhio alle mie tabelle mi sono reso conto di quanto fosse grande wp_postmeta. Esplorandola ho scoperto che il 90% delle righe erano occupate da un plugin (BAW Post Views Count) che si occupa di tenere conto della quantità di visite ricevute per post. Per “l’importanza” del plugin ho reputato che il suo uso della tabella discussa fosse un po’ invasivo. Morale della favola, sconsigio BAW Post Views Count e se implementate un plugin sconsiglio tendenzialmente di utilizzare le tabelle native di wordpress, consiglio di creare delle tabelle ad hoc. Relativamente a BAW Post Views Count ho poi fatto pulizia così DELETE FROM `mydb_postmeta` WHERE `meta_key` LIKE ‘%_count-views_%’   Infine una piccola query che leva di mezzo almeno le righe relative a post che non esistono più. SELECT * FROM {$wpdb->postmeta} as pm LEFT JOIN {$wpdb->posts} as p ON pm.post_id = p.ID WHERE p.ID IS NULL
Read More ›


WordPress sito in multilingua


In qualità di CMS uno dei pochi grandi difetti di WordPress sta nel non essere multilingua (altro grandissimo difetto è quello di avere una scarsissima gestione del livello di accesso, inesistente sulle aree, alberatura di contenuto e creazione gruppi oltre ai ruoli). Dopo aver più volte testato sulla mia pelle le criticità di creare un sito multilingua con wordpress non posso che proporre la lettura di questa completissima guida (chiaramente in inglese)  http://wplang.org/translation-plugins-languages/ . Un piccolo cappello introduttivo alla guida può raccontarvi che ci sono due modi fondamentali per tradurre con wordpress: attraverso un plugin o attraverso l’installazione multi-sito. Dopo un’esperienza scoraggiantissima con QTranslate che nella versione specifica che usai trovai pieno di bachi che risolsi io stesso, altrimenti il sito in questione non avrebbe potuto andare online, ho sempre solo usato WPML che per contro ha dei costi di acquisto. Polylang potrebbe essere un’altrenativa gratuita ma non mi ci sono mai avventurato. Davvero molto più complesso e time-consuming (non tanto per l’installazione quanto per la manutenzione) è la possibilità di creare un multisito. Da wordpress 3 è possibile effettuare una configurazione multisito in cui la stessa installazione condivide gli stessi file di core e plugin, ma tabelle del database diverse […]
Read More ›


Error reporting level in wordpress , gestione avanzata degli errori


In wp-config di wordpress possiamo accendere il debug di wordpress, ma questo ha un livello di on e off non è possibile personalizzarlo. La funzione che si occupa di “accendere” il debug (“sovrascrivendo” la configurazione del vostro server) è wp_debug_mode() che risiede in wp-includes/load.php . Ora per configurare il livello di debug si potrebbe modificare la funzione nelle seguenti righe, da if ( WP_DEBUG_DISPLAY ) ini_set( 'display_errors', 1 ); elseif ( null !== WP_DEBUG_DISPLAY ) ini_set( 'display_errors', 0 ); a if ( WP_DEBUG_DISPLAY ){ ini_set( 'display_errors', 1 ); ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT); }elseif ( null !== WP_DEBUG_DISPLAY ){ ini_set( 'display_errors', 0 ); } ma andare a modificare una pagina php che fa parte del core è concettualmente sbagliato, è un lavoro sporco e sopratutto se un aggiornamento di wordress sovrascrivesse il file la modifica andrebbe persa. La migliore e più semplice strategia per personalizzare il livello quindi è la seguente. Creare in wp-content la cartella mu-plugins (must use plugins). Si tratta di una cartella i cui file vengono chiamati automaticamente e in ordine alfabetico. Create un file php a piacere come ad esempio error-reporting.php e poi inserite ad esempio la seguente riga: ini_set('error_reporting', E_ALL & ~E_NOTICE […]
Read More ›


Child theme in wordpress


Se installate un tema di terzi su wordpress è il caso uno di appurare che si tratti di un tema sicuro e non contenga codici maligni ad esempio con Theme Authenticity Checker (TAC) . E’ poi possibile che il tema sia passibile di aggiornamenti e quindi per evitare che con un aggiornamento il tema e le nostre eventuali modifiche vengano sovarascritte è buona norma creare un Child Theme. Il Child Theme è un tema che eredita le caratteristiche del genitore ma in caso esistano dei file con uno stesso nome i file del genitore subiscono override (direi tutti ad eccezione di style.css e functions.php, che ereditano il codice del genitore e accodano il loro). Per dare luce la tema è necessario creare una cartella nella directory themes che potrebbe essere “mytheme-child” (per creare il child del tema “mytheme”) e inserire un file style.css. Nel file css è necessario dichiarare il seguente codice: /* Theme Name: mytheme Child Description: Tema Child per il tema mytheme Author: Federico Porta Author URI: https://www.federicoporta.com Template: mytheme Version: 0.1.0 */ Perchè l’override avvenga in maniera corretta è ideale creare functions.php e accodare i css del genitore con una funzione <?php add_action( 'wp_enqueue_scripts', 'enqueue_parent_theme_style' ); function […]
Read More ›