Alle volte succedono cose strane nella bacheca di WordPress.

Sono stati effettuati degli aggiornamenti di qualche plugin, tutto è andato bene, ma WordPress continua a evidenziarli come da aggiornare, nonostante la vecchia versione indicata, e quella nuova, siano le stesse.

Oppure sappiamo per certo che alcuni plugin sono da aggiornare, eppure WordPress non li segnala. Di fatto non è possibile aggiornarli, e questo è più grave.

Si può risolvere (momentaneamente) il problema lavorando sul database.

Per prima cosa è meglio fare un bel backup del database, che non si sa mai.

Poi si accede al buon vecchio phpMyadmin (o allo strumento che si utilizza per gestire il database) e si esegue questa query:

update wp_options set option_value='' where option_name='_site_transient_update_plugins';

La query serve per fare un reset della riga _site_transient_update_plugins della tabella wp_options.
Naturalmente occorre sostituire il prefisso standard “wp_” con quello che si è deciso di utilizzare per le tabelle.

Una volta fatto, e ricaricando la bacheca, gli aggiornamenti disponibili vengono nuovamente segnalati, ed è possibile effettuarli. Oppure non vengono più segnalati come da aggiornare, se il problema era questo.

Notare bene che questa operazione non risolve il problema alla radice, il più delle volte si ripresenta ai primi aggiornamenti, ma questo aspetto devo ancora esplorarlo.

Anzi, a tal proposito ogni feedback è particolarmente gradito.

Se la risposta è no, vai nella bacheca di WordPress perché è appena stato rilasciato WooCommerce 2.0.10, che apporta una dozzina di bugfix al popolare sistema di e-commerce per WordPress.

Di seguito le novità della nuova versione 2.0.10 

• Tweak – Searching for SKU in admin panel can also be done via lowercase ‘sku:’ instead of just ‘SKU:’
• Fix – Cast term_id as int in product data write panel that will resolve issues with numerical attributes
• Fix – Correct label for RUB symbol – added a dot after it
• Fix – Javascript escapes to stop breaking scripts when used with translations
• Fix – PayPal button should use classes ‘button’ and ‘alt’, not ‘button-alt’
• Fix – Have the remove_taxes() method set subtotal to subtotal_ex_tax
• Fix – Allow layered nav to work with non pa_ prepended taxonomies
• Fix – Better backwards compatibility with _woocommerce_exclude_image
• Fix – is_on_sale() method now returns true for products with a sale product of 0
• Fix – For when get_the_terms() returns false inside woocommerce_get_product_terms()
• Fix – PayPal has a 9 item limit
• Fix – Replace deprecated wp_convert_bytes_to_hr() with size_format()

Rilancio volentieri questa segnalazione di Andrea Barghigiani su Google+, molto interessante per chi è sempre alla caccia di temi per WordPress, magari gratuiti, ma che soddisfino un minimo di requisiti di qualità.

Di temi gratuiti per WordPress ce n’è a perdersi, ma sulla qualità di buona parte di questi temi meglio stendere un velo pietoso.

Questo non vuol dire che tutti i temi gratuiti siano da cestinare, ma individuare quelli buoni in tanta mediocrità è davvero un’impresa.

C’è un’altra strada, e riguarda i produttori di temi premium.

In genere questi hanno alcuni temi gratuiti in catalogo, per ovvi motivi promozionali. Alle volte si tratta di temi un po’ vecchietti, o che non hanno avuto particolare successo, ma non mancano strutture che, con un po’ di buona volontà, possono trasformarsi in progetti interessanti.

Quelli di wpmu.org hanno avuto una brillante idea, raccogliere cioè in una sola pagina tutti i temi gratuiti messi a disposizione dai principali realizzatori di temi premium, e ne è venuto fuori un elenco di ben 120 temi, che val la pena di tenere a portata di mano: 120 temi gratuiti realizzati da sviluppatori premium.

Sono presenti temi di WooThemes, Colorlabs, WPZoom, WPShower e molti altri sviluppatori premium, alcuni noti ed altri meno. Magari c’è pure qualche sviluppatore sconosciuto che vale la pena di inserire nei bookmark.

I backup di Plesk sono gestibili tramite Backup Manager, dall’interfaccia di Plesk, ma se questa per qualche motivo (o qualche guaio) non fosse disponibile, da terminale è possibile gestire comunque i backup, e relativi restore.

Ovviamente occorre aver pianificato per bene i backup, altrimenti hai voglia a trovar qualcosa da ripristinare.

Se occorre andare da terminale, e se i backup sono stati fatti, occorre prima scovarli. La posizione dei backup, poi, è modificabile direttamente nella configurazione degli stessi backup.

Vediamo come scoprirlo.

Quando la posizione dei backup viene lasciata di default, il percorso è var/lib/psa/dumps/, dove si trovano i backup generali di plesk.

All’interno di dumps si trova la cartella domains dove, divisi per dominio come lo stesso nome lascia intendere, sono suddivisi i singoli backup dei domini, se impostati.

Se però il percorso non fosse quello di default, lo si può scoprire dal file di configurazione di Plesk /etc/psa/psa.conf, eseguendo un semplice grep:

grep DUMP_D /etc/psa/psa.conf

Naturalmente occorre ripristinarli, i backup, e se dall’interfaccia di Backup Manager è intuitivo, dalla shell un po’ meno, ma nulla di improponibile.

Plesk prevede un comando da shell per effettuare sia il backup che il restore, e la documentazione è dettagliata.

Magari in un prossimo post affronteremo anche questo argomento.

Per festeggiare maggio, nella pagina ufficiale delle estensioni di WooCommerce sono arrivati 7 nuovi plugin, che vanno ad arricchire la già nutrita lista delle estensioni selezionate da WooThemes per il popolare plugin per il commercio elettronico per WordPress.

Le estensioni di WooCommerce, val la pena di ricordarlo, altro non sono che dei plugin per WordPress, come tali si installano nel sistema.

Ecco una veloce carrellata delle novità.

I nuovi plugin per WooCommerce:

• RedSys Gateway, gatewat di pagamento per RedSys
• WooCommerce Splash Popup, un popup d’effetto per annunci e informazioni
• Bulk Variation Forms, aggiunge la possibilità di creare comodi moduli di selezione per prodotti con variazioni
• WooCommerce Quick View, visualizzazione rapida tramite popup lightbox delle caratteristiche dei prodotti
• WePay Payment Gateway, gatewat di pagamento per WePay
• Product Retailers, aggiunge la possibilità di acquisti esterni direttamente da altri venditori
• Customer/Order XML Export Suite, esportare gli ordini in XML tramite download, o automaticamente via FTP.

Si tratta di plugin commerciali, i prezzi partono da 29 Dollari US per la licenza singolo sito.

I miei preferiti sono Splash Popup, Quick View e Bulk Variation Forms, ma in futuro potrebbe avere il suo perché anche Product Retailers.

Visto che non si parla mai abbastanza sull’importanza del backup nelle soluzioni web, ho pensato di scrivere quelle che sono le mie procedure per salvaguardare questo mio blog e in genere il mio lavoro da brutte sorprese, malfunzionamenti o peggio.

Chi non ha mai perso dei dati, e valuta queste problematiche con leggerezza, farebbe bene a ricredersi, perché quando capita son davvero dolori.

Peggio ancora, chi credeva di essere al sicuro, ma ha perso comunque dei dati perché non ha mai verificato l’efficacia del proprio backup, oltre ai dolori aggiunge pure la beffa.

Non ci sono scuse, preoccuparsi del backup dei dati è sacro, doveroso e improcrastinabile!

Un backup ben organizzato è l’equivalente di un buon stile di vita: ci si guadagna in salute!

1. Backup conservati in luoghi diversi dallo spazio web
2. Quando possibile, preferire script di backup esterni a WordPress
3. Se non è possibile fare diversamente, BackWPup è il plugin di backup per WordPress che preferisco (al momento).
4. Meglio avere backup  differenti per database e file
5. Backup giornalieri, ma predisporre anche backup con frequenze diverse
6. Verificare spesso l’integrità del backup

Quando il sistema lo consente, io prediligo le soluzioni di backup esterne a WordPress. Mi danno una maggiore sensazione di sicurezza, e non vanno ad appesantire WordPress con l’ennesimo plugin.

Dove salvare i backup?

Il backup non deve essere conservato nello spazio del sito.
Quale sia la soluzione utilizzata, è fondamentale che il backup sia spostato dal server in cui si trova il sito. Automaticamente in fase di backup, o manualmente poi, i backup vanno spostati dal server .
Altrimenti, se il server va a gambe all’aria irrimediabilmente, possiamo dire addio anche ai nostri backup.
Si tratta di situazioni limite, in cui normalmente il fornitore del servizio dovrebbe intervenire con un ripristino del server, ma se il backup del server fosse vecchio di qualche settimana? Meglio cautelarsi.

Backup di WordPress senza plugin

1. Backup tramite script

È la soluzione che preferisco, quando è possibile accedere alla shell, perché è quella che controllo meglio.
Tramite shell script gestiti con cron, per quanto riguarda la programmazione, si creano facilmente dei dump compressi del database, archivi compressi di tutti i file, si possono inviare ad un altro server come deposito, tutto viene scritto in file di log e, in caso di errore, vengono inviate delle mail di notifica.
Non è alla portata di tutti, ma cercando bene in rete si possono trovare molti esempi utili.

2. Backup da pannello di controllo

Molti piani di hosting offrono soluzioni di backup, dei file e dei database, direttamente da pannello di controllo. In taluni casi a pagamento, ma in genere la spesa è contenuta.
Modalità e configurazioni variano da hosting a hosting, a seconda del pannello di controllo utilizzato.
Alcune soluzioni “più furbe” offrono anche la possibilità di salvare i backup su spazi diversi, via FTP o altro protocollo.

Backup di WordPress tramite plugin

Quando non è possibile fare altrimenti, il mio plugin preferito per il backup di WordPress è BackWPup.

La mia configurazione tipo prevede almeno due tipi di backup, uno per il database e l’altro per i files, e di solito scelgo due destinazioni differenti, sia una cartella sul server che Dropbox. Escludo la mail, specie con backup di certe dimensioni.

In tutti i casi lascio sul server, sia locale che Dropbox, almeno le ultime 3 copie dei backup. Anche di più a volte, dipende molto dallo spazio disponibile.

Normalmente predispongo backup con frequenza giornaliera sia per il database che per i files, sia in locale che su Dropbox.

Imposto pure gli stessi backup con frequenze diverse, almeno una settimanale e una mensile, perché se non ci si accorge in tempo di eventuali problemi, è bene avere a disposizione un backup più datato ma “sano”.

Verifica dei Backup

Quale sia il tipo di backup utilizzato, è fondamentale verificare che il backup sia completo e utilizzabile, bastano due semplici prove:

1. Provare a importare il backup del database in MySQL, in una installazione WordPress di prova.
2. Decomprimere il backup dei file e fare il conteggio degli elementi presenti nel backup, provando a campione l’integrità dei files.

La verifica del backup è davvero importante!

Prova ad immaginare la situazione peggiore che potrebbe capitare al vostro sito, e di essere comunque tranquillo perché “tanto c’ho il backup”, per poi scoprire che il backup non è recuperabile, in particolare il database.

Sono sorprese che non auguro a nessuno…

Come sono organizzati i tuoi backup?

C’è una nuova versione di WooCommerce, disponibile tra gli aggiornamenti di WordPress.

La nuova versione 2.0.9 ci riguarda direttamente perché, tra tante piccole migliorie e bugfix, è stata aggiornata anche la localizzazione italiana.

Inoltre è stato aggiunto un nuovo tag condizionale per WooCommerce, is_product_taxonomy().

Maggiori informazioni sull’aggiornamento sono disponibili direttamente nella pagina di WooCommerce. Qui l’elenco completo delle novità della nuova versione di WooCommerce.

Se per caso utilizzate il plugin BackWPup per il backup del vostro WordPress, attenzione che la versione 3.0.9 è ricca di problemi.
In alcuni casi genera degli errori PHP ben visibili, in altri semplicemente non mostra errori particolari, se non alcune parti dell’interfaccia di amministrazione che non si riesce a gestire.

Il problema è stato prontamente risolto nel giro di poco con un aggiornamento, la nuova versione 3.0.10 infatti rimette a posto le cose, con buona pace per i sacrosanti backup.

Se lo utilizzate e non sapete che versione avete in uso, meglio fare un controllino e, nel caso, aggiornare.

Tempo fa mi è capitato di discutere di siti internet, posizionamento, social media marketing e compagnia bella con il titolare di una piccola azienda, ma soprattutto dell’importanza di taluni strumenti rispetto ad altri, di come cercare di ottenere il meglio da tutti.

Ero rimasto perplesso dalla sua decisione di concentrare tutti gli sforzi comunicativi sui social network, togliendo addirittura di mezzo sito e blog, e facendoli reindirizzare alla pagina Facebook.

Per carità, in guerra e in rete tutto è lecito, io però rimango ancora un fervente sostenitore del sito Internet, delle sue evoluzioni, e del blog come fulcro della comunicazione in rete, sia personale che aziendale.

Tutto il resto sono strumenti utili, e pure parecchio intendiamoci, per portare visite e contatti al blog, centro gravitazionale dell’attività in rete.

Il buon vecchio sito web, con la sua libertà creativa e comunicativa pressoché totale, ritengo sia ancora il modo migliore per esprimere il carattere e la personalità di un’azienda, aggiungendo punti distintivi che altri mezzi ancora non possono offrire. Social network e il social media marketing, per quanto in continua evoluzione, mi sembrano sempre limitati da questo punto di vista.

Di recente, ho apprezzato un articolo di  un esperto in comunicazione che stimo in modo particolare, Riccardo Scandellari sulla centralità dei blog, che consiglio a chi volesse approfondire la questione.

WooCommerce è il ben noto plugin per WordPress di WooThemes per il commercio elettronico. Gratuito, non ha bisogno di molte presentazioni specie per chi segue questo blog, tanto che ho recentemente deciso di dedicare una categoria solo per WooCommerce.

Il fatto che WooCommerce sia un plugin gratuito, non sempre significa che ci possa realizzare un e-commerce gratuitamente.

Molti dei plugin che possono tornare utili sono a pagamento, e i meno esperti, i non addetti ai lavori, potrebbero avere difficoltà nella configurazione o gestione dell’e-commerce senza un minimo di assistenza.

La novità è che WooThemes sta inaugurando la nuova versione del supporto professionale per WooCommerce, per ora in versione beta.

Il servizio è a pagamento, ed è destinato a sviluppatori ed utilizzatori avanzati di WooCommerce, ed i prezzi sono “adeguati”, variano da 329 a 1.999 Dollari US l’anno.

WooCommerce continuerà ad essere un plugin gratuito e Open Source, e la documentazione rimarrà anch’essa gratuita, sempre molto utile per chi vuole cimentarsi nella realizzazione del proprio e-commerce con WooCommerce.

Questo significa che sarà ancora possibile continuare a realizzare siti di e-commerce efficaci, a costi estremamente contenuti.

Cambierà qualcosa per chi invece ha personalizzato in modo importante il proprio store basato su WooCommerce, non solo esteticamente, o per quegli sviluppatori o consulenti che vogliono differenziare la loro offerta con la qualità di un supporto rapido e risolutivo.

In questi casi, avere a disposizione il supporto diretto di WooThemes potrebbe significare la soluzione rapida di tanti problemi.

Inevitabilmente questo andrà ad influire sulle tariffe di chi realizza e offre supporto per siti di e-commerce realizzati con questo plugin, che troveranno in questo supporto una miniera di informazioni particolarmente utili per migliorare e rendere più efficace la propria offerta.

Ve l’ho mai detto che io ho diverse installazioni di WooCommerce all’attivo?

Le scorse settimane sono state caratterizzate da un allarme sicurezza per WordPress, con segnalazioni di violazioni più o meno ovunque. Io sono stato contattato per risolvere quattro WordPress bucati, quasi tutti con la stessa tecnica.

(a proposito, sta girando un altro allarme di sicurezza per due noti plugin…)

Dei WordPress che gestisco direttamente, miei o di miei clienti, solo uno ha avuto problemi, ma la violazione sono convinto sia arrivata non tramite il CMS o i suoi componenti, bensì dal server che lo ospita.

Sugli hosting condivisi, se la sicurezza non è particolarmente curata, può succedere infatti che bucano un server e che, una volta dentro, riescono a fare danni su diversi domini dello stesso server.

Per quello che è la mia esperienza, la maggior parte di casi come questi, dove non si tratta della volontà di far danni ad uno specifico sito o servizio ma di azioni su larga scala, i problemi di sicurezza riguardano soprattutto siti che non applicano neanche le più elementari precauzioni.

La sicurezza assoluta non esiste, intendiamoci, ma così significa andarsela a cercare…

Un’altra cosa che ho notato, in questi casi, è che chi cura poco i fondamentali della sicurezza, che oramai si possono leggere ovunque, sono anche quelli che non si preoccupano più di tanto nemmeno dei backup.

Oppure ci sono quelli che si sentono tranquilli, perché tanto hanno installato il plugin che ci pensa per loro, ma non si sono mai presi la briga di verificare che i backup effettuati corretti e consistenti, utilizzabili cioè per ripristinare un WordPress danneggiato.

Ora, visto che l’elisir della sicurezza totale non lo conosce nessuno, almeno sinceriamoci che i backup ci siano e funzionino bene!

Certe trascuratezze si pagano, nel vero senso della parola. Buon per me che questo giro ero dalla parte di chi si è fatto pagare per sistemare le cose…

Allarme sicurezza per i plugin WP Super Cache e W3TC Total Cache

Dato che parliamo di vulnerabilità, in questi giorni sta girando una nota su gravi problemi di sicurezza di WP Super Cache e W3TC Total Cache, due plugin molto utilizzati per velocizzare WordPress tramite sistemi di cache.

Vanno assolutamente aggiornati entrambi, che le nuove versioni appena rilasciate mettono al sicuro dalle vulnerabilità appena individuate.

Come ad esempio la segnalazione di aggiornamenti riguardo il tema in uso, che purtroppo non funziona per niente bene con  parecchi hosting.

Nelle impostazioni del framework, sono infatti previste due voci (di default non sono attive):

1. la notifica di eventuali aggiornamenti del framework
2. la notifica di eventuali aggiornamenti del tema in uso

Se attivate, gli aggiornamenti del framework sono notificati senza alcun problema, all’interno del pannello di controllo. Un paio di click e si può procedere all’aggiornamento in modo semplice e indolore (backup sempre e comnque!)

Non si può dire altrettanto con le notifiche riguardante la versione del tema in uso. In caso di aggiornamenti, è raro che vengano segnalati.

Interpellati, quelli di WooThemes con molta correttezza non nascondono il problema, ne sono consapevoli, e contano di rivedere completamente il sistema di notifica e di aggiornamento del tema in uso, dal pannello di controllo, entro l’anno.

Nel frattempo, tocca andare spesso nel proprio account sul sito WooThemes, alla voce download, e verificare che non ci siano nuove versioni disponibili dei temi acquistati.

Nel caso, un bel backup che non si sa mai e si può procedere con l’aggiornamento manuale.

Perché è importante aggiornare il tema di WordPress?

1. Può essere un aggiornamento di sicurezza (!!!)
2. Può apportare bugfix
3. Può apportare migliorie alle funzionalità
4. Può apportare nuove funzionalità al tema
5. Può apportare miglioramenti delle prestazioni
6. Può significare una maggior ottimizzazione delle risorse
7. Può apportare maggior compatibilità con l’ultima versione di WordPress

Sono motivi abbastanza validi per tenere il tema aggiornato?

Ma se si frequentano le varie community on line dedicate a WordPress, in effetti la presenza femminile scarseggia. Non credo ci sia una rapporto, e soprattutto che rispetti la realtà, specie in ambito professionale. Nei WordCamp sparsi sul territorio poi, almeno sul palco, non ne parliamo.

L’immaginario vuole questi ambienti, fatti di sviluppatori e web designer, una prerogativa di giovani nerd brufolosi, rigososamente occhialuti e maschietti, ma noi sappiamo che la realtà è molto diversa.

Lo è ancor più in ambito professionale, dove il gentil sesso, alle prese con WordPress, è capace di esprimere sensibilità e creatività che noi maschietti possiamo solo scopiazzare.

Forse bisognerebbe chiederlo direttamente a loro, alle dirette interessate, come mai ci sono così poche rappresentanti a discutere di CMS, sarebbe interessante conoscere la loro versione e visione.

Disinteresse loro o colpa nostra?

Dopo la pubblicazione dell’articolo riguardante la ricerca degli errori di WordPress, mi sono arrivate diverse mail con richieste di delucidazioni. In particolare sul debug di WordPress, così ho pensato che un approfondimento potesse tornare utile.

Il debug di WordPress è sicuramente il miglior strumento di diagnostica che il nostro CMS preferito ci mette a disposizione, senza dover ricorrere a strumenti esterni o a plugin.

Utile in caso di malfunzionamenti,  per la verifica del codice in fase di sviluppo di soluzioni, e in generale per la verifica del corretto funzionamento o dell’ottimizzazione del sito.

In linea di massima, basta semplicemente attivare il debug, direttamente nel file di configurazione di WordPress. In caso di problemi, errori di PHP o semplici avvisi di anomalie, questi vengono visualizzati nelle pagine.

Le possibilità offerte dal debug non si fermano qui, vale la pena di approfondirle.

Come abbiamo già visto, per l’attivazione del debug si deve modificare un’istruzione nel file wp-config.php, il file di configurazione di WordPress:

define('WP_DEBUG', true);

Il valore di default è false, bisogna modificarlo in true.

In questo modo si attiva la visualizzazione degli errori direttamente sulle pagine del sito. Può tornare utile in situazioni straordinarie, ma è preferibile che gli errori siano scritti in un file di log, per una migliore consultazione e lontano da occhi indiscreti.

Specie se si tratta di un sito funzionante e visibile al pubblico, gli errori visualizzati direttamente sulle pagine sono indice di poca professionalità, possono creare confusione e sconcerto nei visitatori. Meglio quindi nasconderli alla vista.

La scrittura di un file di log e la disabilitazione degli errori a video sono alcune delle opzioni possibili, attivabili sempre nel file di configurazione di WordPress, wp-config.php.

Ecco un esempio di una configurazione di debug, che comprende una carrellata delle principali opzioni possibili:

// Abilitare la modalità debug
define('WP_DEBUG', true);

// Abilitare la scrittura del file di log del debug /wp-content/debug.log
define('WP_DEBUG_LOG', true);

// Disabilitare la visualizzazione di errori e notifiche
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

// Abilitare il debug di script JS e CSS
define('SCRIPT_DEBUG', true);

Aggiungendo le istruzioni qui sopra nel file wp-config.php andiamo ad ottenere una situazione ottimale di debug dove:

1. Il debug di WordPress è attivo
2. Gli errori (anche quelli diretti del PHP, riga 9) non vengono visualizzati ai visitatori, ma scritti in un file di log dentro la cartella wp-content
3. Viene attivato il debug anche per gli script JS e CSS

Le query al database

C’è un’ultima opzione possibile, che consente di salvare il risultato delle query al database in un array, una variabile.

define('SAVEQUERIES', true);

Questa possibilità va usata solo quando strettamente necessario, perché ha un impatto molto pesante sulle prestazioni di WordPress.

Per visualizzare o salvare in un file di log il risultato, bisogna lavorar di codice. In rete ho trovato due esempi che possono tornare utili:

• Visualizzare le query del database
• Salvare le query al database di WordPress in un file di log

Personalmente, per maggior praticità, e perché un file di log può sempre tornare utile, preferisco la seconda possibilità.

Ultima nota utile: la pagina del codex di WordPress dedicata al debug.

Interpretazione delle informazioni di debug

Ora che si è attivato il debug su WordPress, arriva la parte più difficile: interpretare le informazioni su errori e notifiche.

Avere la lista degli errori, ma non sapere cosa significhino, è come non avere nulla.

Ad onor di cronaca, va comunque detto che, nel caso di un WordPress in stato di grazia, il log del debug potrebbe anche essere vuoto, non riportare cioè assolutamente nulla. È normale, anche se raro: niente errori o avvisi, niente da segnalare nei log.

Più probabile invece che qualche notifica, anche solo dei semplici avvisi, vengano comunque fuori.

Spesso si tratta di funzioni deprecate, cioè temi o plugin che fanno uso di funzioni di WordPress, dismesse o in via di dismissione, che dovrebbero essere sostituite con altre pù attuali o corrette. Di solito succede con plugin o temi non aggiornati da tempo.

In altri casi invece si tratta di errori veri e propri, che possono compromettere il buon funzionamento del sito a vari livelli.

Nei casi più gravi, vanno comunque sempre tenuti in considerazione i file di log di errore del server web, sempre molto ricchi di informazioni utili.

Spesso San Google aiuta a scoprire le cause di questi errori. Spesso fornisce pure indicazioni su come risolverli, ma occorre una certa dose di domestichezza con il codice di WordPress, temi e plugin, per venirne a capo

In ogni caso, avere delle informazioni di debug è già un buon inizio.

Queste informazioni si possono fornire nei vari forum di supporto o nelle community tematiche, per cercare un aiuto, oppure girarle a chi si decide di interpellare per avere un’assistenza su WordPress.

Ecco l’elenco delle novità di questo aggiornamento:

• New Updated UI
• New Module System, Feature Manager
• New Performance Module
• New options for controlling title rewrites
• Advanced settings for controlling titles on custom post types
• Option to show hidden custom meta fields
• Quick edit SEO options from the Edit All Posts/All Pages screens.
• Uses WordPress admin pointer feature.
• Added preview snippet
• Added noindex, nofollow to All in One metabox options
• Added webmaster verification options for Google, Bing, and Pinterest
• Added optional admin bar menu
• Added initial Slovakian translation
• Updated POT for translators
• Bugfixes

Maggiori info su: All in One SEO Pack Changelog.

La maggior parte delle richieste di aiuto, che ricevo tramite questo blog, riguardano malfunzionamenti di WordPress.

Alla domanda di rito:

Cos’hai fatto prima che WordPress cominciasse a dare problemi?

La risposta è quasi sempre la stessa:

Io? Niente…

Normale, ormai ci sono abituato.

Il più delle volte la soluzione al problema è solo dietro l’angolo, basta dare un’occhiata veloce per capire che il malfunzionamento è causato dall’attivazione o dall’aggiornamento di un plugin o di un tema.

Capita spesso, specie se si sta vivendo il periodo della “installazione compulsiva di temi e plugin“, tipica di chi ha scoperto da poco le meraviglie di WordPress.

In genere basta armarsi di pazienza, e individuare il colpevole andando per esclusione. Disattivando plugin e temi possibilmente in ordine cronologico, iniziando cioè dall’ultimo installato o aggiornato, ed in genere l’infingardo lo si stana in breve tempo.

Talvolta la faccenda è un pochino più complicata.

Magari si tratta di un WordPress su cui il proprietario si è divertito a giocare con il codice, o ci sono problemi con il database.

Per cercare di arrivare almeno ad una diagnosi, abbiamo due strumenti importanti:

1. Il debug di WordPress
2. I file di log del server web

Attivare il debug di WordPress

Se il WordPress malandato non è del tutto defunto, è possibile avere informazioni utili attivando il debug direttamente dal file di configurazione di WordPress, wp-config.php.

Basta semplicemente trovare la riga riguardante il debug e modificarla come segue:

define('WP_DEBUG', true);

Il valore di default è false, bisogna modificarlo in true.

Una volta modificato, è possibile che le pagine del sito si riempiano di strane scritte e messaggi di errore.

Consultare i log del server web

Oramai praticamente tutti gli hosting forniscono un pannello di controllo per la gestione del sito, tramite il quale si possono consultare anche i file di log del server web, sia quelli di accesso che quelli di errore. I più importanti, in questo caso, sono ovviamente quelli di errore.

Se i log non sono disponibili, meglio contattare il proprio fornitore del servizio e richiedere che lo siano. Anche per il futuro, perché potrebbero essere di aiuto in molte occasioni, dai malfunzionamenti alle violazioni del sito, riuscite e non.

Interpretare i messaggi di errore di  WordPress o del Server

Ecco, decisamente questa è la parte più difficile, anche se talvolta basta copiare l’errore, incollarlo su San Google.

Spesso e volentieri è un errore già capitato a qualcun altro e la soluzione, o almeno qualche dritta per arrivarci, potrebbe saltar fuori già così.

Se non ci si salta fuori, sono comunque informazioni importanti, da conservare e passare a chiunque si voglia interpellare per avere assistenza su WordPress.

Considerazioni extra sul debug di WordPress

Attivare il debug di WordPress potrebbe tornare molto utile, non solo in caso di problemi.

Alle volte siamo convinti che il nostro bel sito stia girando come un orologio, ma in realtà potrebbe nasconde piccoli problemi o malfunzionamenti. Magari nulla di percepibile visivamente, ma che potrebbero causare rallentamenti più o meno sensibili. Magari i soliti plugin, vecchi, troppi o dispettosi, o un tema che non viene più aggiornato da troppe versioni di WordPress…

Di tanto in tanto attivare il debug di WordPress, giusto per scrupolo, potrebbe metterci al riparo da brutte sorprese.

Lo è sicuramente in fase di avvio di un sito, quando ottimizzare le risorse è fondamentale anche solo per avere buone prestazioni.

Approfondimento: le opzioni principali del debug di WordPress

Per l’occasione, ho pensato di sfruttare il servizio “Pay with a Tweet“, anche per provarlo (e un po’ di pubblicità non guasta…). Quindi se vuoi i file di traduzione, devi “pagarli” con un tweet o un post su Facebook o Linkedin, più facile a farlo che non a dirlo.

La traduzione l’ho effettuata soprattutto per le poche diciture che appaiono sul frontend, anche se ho tradotto tutte le voci. Alcune traduzioni potrebbero essere frettolose o comunque migliorabili, sono gradite tutte le segnalazioni in tal senso.

L’utilizzo è semplice e alla prova di tutti:

1. Se non ce l’hai ancora, scarica e installa il plugin originale sul tuo WordPress, altrimenti passa al punto successivo
2. Manda un tweet (o un post su Facebook o Linkedin) tramite il link qui sotto per il download della traduzione
3. Scarica e decomprimi la traduzione in italiano
4. Copia i due file di traduzione nella cartella “wp-content/plugin/limit-login-attempts/” del tuo WordPress

Da quel momento il plugin Limit Login Attempts parla in italiano.

Paga con un Tweet e scarica la traduzione

In caso di aggiornamenti del plugin, è necessario ripetere l’installazione dei file di localizzazione.
La localizzazione è stata effettuata sulla versione 1.7.1 del plugin, tornare su questa pagina per eventuali aggiornamenti.

Nota bene: la traduzione non è una localizzazione ufficiale del plugin, leggere il file leggimi.txt che l’accompagna per le istruzioni d’uso e le note di utilizzo.

Sarà una coincidenza, ma la sensazione è che in tantissimi, negli ultimi mesi, abbiano scoperto l’e-commerce, ed in particolare l’e-commerce con WordPress, tramite WooCommerce.

Sarà perché WordPress è notoriamente amichevole e intuitivo, sarà che anche WooCommerce in quanto a facilità d’uso non scherza, ma da qualche mese le richieste di informazioni e di assistenza sono decuplicate, almeno per quanto mi riguarda.

Ma è davvero solo una questione di praticità e facilità d’uso?

Io ho l’impressione che la crisi che ci attanaglia c’entri parecchio, e che imprese di ogni misura, piuttosto che artigiani e piccoli commercianti, cerchino nel commercio elettronico un’alternativa, qualcosa che smuova le acque stagnanti di una economia al collasso.

Un’alternativa magari snobbata fino a ieri, spesso sbagliando, per svariati motivi.

E-commerce, può funzionare?

Difficile dirlo, bisogna valutare caso per caso, e comunque si tratta sempre di valutare un certo margine di imprevedibilità. Una scommessa, se vogliamo.

Via ogni falsa speranza, diffidare assolutamente da chiunque prometta guadagni facili, fatturati triplicati come mi è capitato di sentir dire, semplicemente aprendo una vetrina sul web.

Bastasse solo installare un plugin, e riempirlo di prodotti, la rete sarebbe piena di commercianti che fanno soldi a palate. Quelli che riescono a vendere, invece, sono pochi.

E-commerce che funziona, cosa fa la differenza?

L’e-commerce è un canale commerciale come altri. Richiede meno investimenti, ma non è gratis.
Non ha bisogno di una rete commerciale fisica, ma va assolutamente messo nelle condizioni di poter vendere.

Deve essere ben fatto. Chi comprerebbe il pane da un negozio con le ragnatele in vetrina?

Bisogna promuoverlo, con le logiche del marketing in rete.

Bisogna dargli carattere, autorevolezza e personalità, doti che andranno a riflettersi poi sui prodotti, e che convinceranno i visitatori a prendere questi piuttosto che altri.

L’occhio del padrone ingrassa il cavallo, anche qui…

Insomma la crisi spinge a cercare mercati alternativi, e per molte aziende l’e-commerce può essere davvero uno strumento valido, ma nessuno creda di realizzarlo e poi via, che tanto vende da solo.

Non funziona così.

Se però parliamo di un lavoro, di un sito che stai realizzando per un cliente, beh questi particolari possono avere la loro importanza, ed a volte anche la differenza.

Per fortuna, molti di questi dettagli possono essere risolti facilmente, con piccoli interventi di modifica.

Per modificare il mittente di default delle mail che arrivano da un WordPress, basta aggiungere un filtro al file functions.php, come questo:

add_filter('wp_mail_from', 'new_mail_from');
add_filter('wp_mail_from_name', 'new_mail_from_name');
 
function new_mail_from($old) {
 return 'ilmioblog@nomedominio.it';
}
function new_mail_from_name($old) {
 return 'Questa mail ti arriva dal tuo Blog';
}

Bisogna solo avere l’accortezza di personalizzare la quinta e l’ottava riga.

La solita avvertenza riguardo il file functions.php: se si utilizza un tema child, come raccomando sempre, non conviene modificare il file functions.php del tema originale. Piuttosto creare un nuovo file omonimo nella cartella del tema child, con le sole funzioni e filtri da aggiungere.