Archives For In Evidenza

La primavera è già passata da qualche tempo, ma il mio evidente ritardo nel percepirla ha fatto slittare in avanti dei lavori di pulizia che rimandavo da troppo tempo. Il mio profilo principale di Firefox (costantemente replicato e sotto backup) conteneva dati davvero troppo vecchi, facendo arrivare alcuni dei database SQLite dell’applicativo a occupazioni disco fuori (e di molto) dallo standard al quale si è abituati nelle nuove installazioni (o nei profili più puliti). Per questo motivo ho scelto di prendere scopa, paletta e smacchiatore per dare un po’ più di piglio energico al browser di casa Mozilla, il predefinito sulle mie macchine.

Firefox: ottimizzazione dei DB SQLite 6

Ti spiego in poche parole (e diversi dati) ciò che ho fatto. Ti mando subito a leggere qualche riga riguardo SQLite nel caso in cui non sapessi di cosa si sta parlando, male non può certamente fare. I file incriminati e importanti sono sostanzialmente due: places.sqlite e webappsstore.sqlite. Prima di partire, una giusta cultura di base: il primo file (database, in realtà) contiene tutta la cronologia di navigazione in base ai criteri da te impostati all’interno delle opzioni di Firefox, non contiene i Segnalibri contiene i Segnalibri nella tabella moz_bookmarks, che viene toccata durante la pulizia solo per rimuovere spazi lasciati vuoti dall’utilizzatore (qui la pagina di KB su mozillaZine). Il secondo file invece conserva i dati che generalmente si vanno a compilare nelle form dei siti web che visitiamo, si tratta di un database molto delicato che non andrebbe mai modificato manualmente e che puoi permetterti di perdere solo se non ti secca ricominciare a creare una cronistoria dei dati che dovrai inserire a mano (per esempio) durante la registrazione di un modulo, una nuova iscrizione a chissà quale forum o così via (qui la pagina KB su mozillaZine).

Sia chiaro: Firefox continuerà a funzionare sulla tua postazione anche se cancelli completamente i due file, poi però non lamentarti se vai a perdere la cronologia di navigazione o i dati precedentemente immessi nei moduli (e non solo), di sicuro ci guadagni in velocità :-)

Io ho voluto clonare il profilo e mettere alla prova un’estensione che promette di andare ad alleggerire questi due file a patto di trovare delle voci orfane, quindi eliminabili in via definitiva, ricostruendo il database e popolandolo solo con le voci effettivamente vive e vegete (vedi: vacuum SQLite). L’estensione è Places Maintenance e la puoi trovare ovviamente su AMO:

Places Maintenance
Places Maintenance
Developer: Mak
Price: Free

Perché proprio lei in un mare di altre estensioni dedicate alla manutenzione dei database SQLite di Firefox? Perché è sviluppata da un amico connazionale e profondo conoscitore di Firefox, Mak, Firefox Team Engineering Consultant.

A installazione terminata (non richiede riavvio, nda) ho lanciato immediatamente una scansione della situazione sul profilo clonato, questo il risultato:

Statistics
 Database size is 81920 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 104024 records
 Table moz_historyvisits has 281408 records
 Table moz_inputhistory has 469 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 4080 records
 Table moz_annos has 2192 records
 Table moz_anno_attributes has 13 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 6291 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex

Occhio a:

  • Database size is 81920 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 104024 records
  • Table moz_historyvisits has 281408 records

Ho volutamente evidenziato i valori più importanti a livello di onerosità su database, ciò che più occupava il file SQLite era chiaramente il contenuto della mia cronologia, praticamente quasi mai resettata. Il valore massimo delle pagine uniche memorizzate nella cronolgia è fisso a 104858 poiché dettato da una configurazione di about:config, per l’esattezza si tratta di places.history.expiration.transient_current_max_pages.

Firefox: ottimizzazione dei DB SQLite 2

Ho lanciato un’ottimizzazione senza toccare alcunché, provando a lasciare invariato il contenuto della navigazione passata e ho dato un’occhiata ai risultati:

Statistics
 Database size is 71680 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 104026 records
 Table moz_historyvisits has 281412 records
 Table moz_inputhistory has 469 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 4080 records
 Table moz_annos has 2192 records
 Table moz_anno_attributes has 13 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 6291 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex
  • Database size is 71680 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 104026 records
  • Table moz_historyvisits has 281412 records

Un risparmio sicuramente interessante, ma sceso appena di –circa– 10 MB, ancora poco in confronto a un file che superava gli 80MB. Ho quindi scelto di mantenere esclusivamente gli ultimi 6 mesi di cronolgia di navigazione del browser, ottenendo (tramite lo stesso procedimento) un risultato nettamente più significativo:

Orphans expiration
 + Database cleaned up
 > Coherence check
 + The database is coherent
 > Vacuum
 Initial database size is 71680 KiB
 + The database has been vacuumed
 Final database size is 30720 KiB
  • Initial database size is 71680 KiB
  • Final database size is 30720 KiB

Un risparmio di circa 50MB rispetto al file originale, un sacrificio più che accettabile considerando che in 6 mesi ho certamente visitato siti web ai quali sono solito passare a fare un saluto, perdendo chi probabilmente non utilizzo così frequentemente (o non utilizzo più, tanto per farla più drastica). Il nuovo report fatto girare subito dopo il vacuum parla chiaro:

Statistics
 Database size is 30720 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 40051 records
 Table moz_historyvisits has 55735 records
 Table moz_inputhistory has 165 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 2036 records
 Table moz_annos has 819 records
 Table moz_anno_attributes has 12 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 3313 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex
  • Database size is 30720 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 40051 records
  • Table moz_historyvisits has 55735 records

Partito con un places.sqlite da più di 80MB e un webappsstore.sqlite da circa 101MB, mi ritrovo con 30MB circa di database cronologico ma un webappstore.sqlite ancora particolarmente obeso.

Ho cercato altri casi simili e mi sono imbattuto su una segnalazione di BugZilla: bugzilla.mozilla.org/show_bug.cgi?id=857888. È partita da un problema relativo a Firefox sul mondo Mobile, ma pare soffrirne anche la versione PC, come confermato anche da una discussione su Reddit (r/firefox)

PSA: Large webappsstore.sqlite file in your profile will heavily affect the responsiveness of Firefox’s UI from firefox

La scelta drastica? Rinominare il database webappsstore.sqlite per non farlo più trovare a Firefox (ovviamente chiuso) il quale lo ha creato da zero una volta riaperto, ho provato così a perdere la cronologia dei moduli e delle applicazioni utilizzate fino a quel momento:

Firefox: ottimizzazione dei DB SQLite 1

Il risultato? Ho utilizzato il profilo sul quale ho effettuato manutenzione per una settimana, ritenendolo adatto a diventare il principale perché la “perdita” non giustificava (secondo me) i rallentamenti sporadici del browser. Oggi sono fermamente convinto di aver fatto la scelta migliore, anche se fino a quando ci saranno siti web contenenti schifezze in Flash e simili, si continuerà ad avere un’occupazione importante del plugin-container.exe che permette a plugin (come quello Adobe) di girare in background, nonostante il Click-2-Play.

Occhio sempre a ciò che fai e dove metti le mani, ma mai abbandonare il tuo fido strumento di navigazione, potrebbe risentirne pesantemente la tua pazienza! ;-)

Ultimo aggiornamento: 5/7/16 10:20
Corretto dettaglio sui Segnalibri in places.sqlite (https://twitter.com/Gioxx/status/750243831132585985)
Condividi l'articolo con i tuoi contatti:

Da poco acquisito da Microsoft, LinkedIn è il Social Network dedicato ai professionisti del lavoro (almeno secondo una parte dei suoi frequentatori, per altri invece proprio no). Spesso utilizzato come concentratore di contenuti, sta prendendo sempre più piede come strumento di pavoneggiamento di massa, altalenando profili effettivamente invidiabili a quelli che pensano di aver messo in piedi una Corporation solo tramite il proprio account di Facebook. A me non importa chi tu sia su LinkedIn, mi importa che il tuo profilo venga tenuto al sicuro, possibilmente con una verifica in due passaggi, ormai disponibile da tempo anche da queste parti.

Sicurezza: la 2-step verification di LinkedIn 2

La verifica in due passaggi è un argomento a me molto caro, è un ulteriore layer di sicurezza che protegge il tuo account da attacchi e furti di identità che in questi nostri tempi sono sempre più comuni a causa della scarsa attenzione che noi tutti riponiamo verso le nostre password, barriera unica tra un accesso autorizzato e uno che di autorizzato non ha proprio nulla. Personalmente cerco sempre di attivare tutti gli step di sicurezza disponibili per proteggere ogni mio account, in aggiunta al fatto di utilizzare una password sempre diversa per ogni iscrizione (quindi per ogni servizio / sito web) e un database mantenuto aggiornato con tutte le mie credenziali (e ben custodito, possibilmente fuori dalla portata di chiunque).

Per poter attivare la verifica in due passaggi di LinkedIn basta puntare all’URL linkedin.com/psettings/privacy. Da qui ci si sposta nell’area Protezione e si procede con l’attivazione della verifica 2-Step.

Sicurezza: la 2-step verification di LinkedIn

Una volta arrivato il codice di protezione via SMS al tuo numero di cellulare (che dovrà essere quindi specificato all’interno del profilo LinkedIn) ti basterà inserirlo nel box che comparirà a video, così da confermare la propria identità. Una volta fatto, la verifica in due passaggi sarà abilitata, così come confermato a video:

Sicurezza: la 2-step verification di LinkedIn 1

Ciò significa che ogni volta che tenterai di accedere a LinkedIn da una postazione non precedentemente collegata (o sulla quale hai effettuato un Logoff manuale) dovrai attendere la consegna di un nuovo codice di sicurezza sul tuo numero di cellulare, che dovrà accompagnare una immediatamente precedente autenticazione basata (come è normale che sia) sull’accoppiata username / mail di registrazione e password.

Il processo è talmente rapido e banale che è alla portata di tutti, usa 2 minuti del tuo tempo per mettere un po’ più al sicuro il tuo account di LinkedIn. Se proprio ci tieni, ti invito anche a seguire e recuperare gli articoli pubblicati sotto il tag 2-step-verification, cerco sempre di inserirne di nuovi per farti scoprire tutti i servizi che permettono l’autenticazione a due fattori, decisamente più robusta rispetto a quella tradizionale.

Enjoy!

Condividi l'articolo con i tuoi contatti:

Credo che VMWare ci prenda gusto a rendere più difficile la vita ai suoi utilizzatori (non sempre forse, ma qualche volta si, dai). Con l’avvento della release 5 del suo vCenter, ha introdotto la gestione tramite interfaccia web. Pesante, macchinosa, utilizzarla era tutto fuorché piacevole. Poco male però, il cliente vSphere per Windows ha continuato a resistere e io ho potuto utilizzarlo senza accorgermi di nulla. Con l’arrivo però del vCenter 6, l’azienda ha ben pensato di spingere ulteriormente l’acceleratore sul suo client di gestione web, andando a togliere funzionalità a quello tradizionale, come una delle tab che ho sempre adorato: quella della Storage View, che mi ha permesso vita natural durante di accedere rapidamente alla vista delle snapshot lasciate in giro.

vCenter 6: gestione Snapshot 3

Ora, tanto per chiarire, non sto parlando della nuova interfaccia web HTML5 che dobbiamo ancora tirare in piedi in ufficio (se ne parla qui: labs.vmware.com/flings/vsphere-html5-web-client#summary), ma di quella inizialmente pensata e rilasciata dall’azienda americana. Molto cambierà in futuro, ne sono certo, e spero di poter abbandonare a cuor leggero il vecchio software ormai considerato obsoleto. Nel frattempo il problema va risolto, perché è diventato pressoché impossibile vedere e filtrare in maniera chiara le macchine che hanno almeno una snapshot lì di fianco, a occupare spazio sullo storage, magari inutili perché create prima di un aggiornamento e poi dimenticate.

Riepilogo quello che VMWare chiede: PowerCLI (addon per la PowerShell in versione 3.0, adattata e pronta a collegarsi al vCenter di nuova generazione), un po’ di conoscenza del mondo PowerShell di Microsoft e buona volontà per mettersi in testa che no, nella vecchia maniera non puoi più filtrare le snapshot che hai seminato nel vCenter, traduco quindi in codice:

Connect-VIServer $INDIRIZZOVCENTER
Get-VM | Get-Snapshot | select VM,Name,@{Label="Size";Expression={"{0:N2} GB" -f ($_.SizeGB)}}

Ricerca e risultato in output (con relativa occupazione disco) sono merito di un thread preso su serverfault.com/questions/644132/getting-a-list-of-all-the-snapshots-in-vms-managed-by-vcenter (dove in realtà c’è anche più roba, ma non serve al mio scopo). Il risultato rispecchia perfettamente la richiesta iniziale:

vCenter 6: gestione snapshot

Il problema nasce però dal fatto che sulla stessa macchina io utilizzo PowerShell per altri lavori, soprattutto per gestire il server Exchange in cloud. La versione 3.0 del tool introduce alcune novità che vanno a far botte con i miei script PS1, cosa assai poco gradevole visto l’alto utilizzo degli stessi nell’arco della giornata (della settimana, del mese, ecc.). Ho quindi spostato la trousse dei necessari su una macchina virtuale, dove posso permettermi di dedicare (o quasi) la PowerShell a VMWare.

Esiste l’alternativa?

Fortunatamente si, e non porta la firma di VMWare, ma di una terza parte sotto la benedizione di Veeam Software. Si chiama RVTools, il suo sito web ufficiale è robware.net. Si occupa di raccogliere tutte le informazioni (ma proprio tutte) dell’installazione vCenter, comprese le snapshot che pascolano libere nello spazio disco, il tutto senza conoscere una riga di codice PowerCLI e senza la necessità di installare KB di Windows e altri prodotti VMWare. Tutti i dettagli sono disponibili all’indirizzo robware.net/index.php/5-sectionarticle/category/29-rvtools-home.

Ma funziona?

Funziona, e anche piuttosto bene. Mi sono collegato al vCenter tramite autenticazione passthrough di Windows (quindi non ho dovuto re-inserire le credenziali, ha utilizzato le mie di dominio), ho lasciato che l’applicazione raccogliesse le informazioni e ho potuto sfogliare il risultato come fosse un enorme catalogo ben organizzato tra le varie tab e colonne per ciascuna di esse, compresa una dedicata esclusivamente alle snapshot:

vCenter 6: gestione snapshot 1

L’elenco è consultabile, oltre che dall’applicazione, anche via Excel, perché RVTools permette l’esportazione in file XLS e CSV (dal menu File). Ogni voce di menu consentirà poi di esplorare le informazioni raccolte e organizzarle secondo le proprie esigenze. Comodo, intuitivo, veloce (una volta raccolte le informazioni però, la prima fase è tanto lunga quanto più sono le macchine gestite dal vostro vCenter). È poi possibile utilizzarlo tramite prompt dei comandi o batch perché accetta parametri da riga di comando.

Supponendo che il vostro utente di dominio sia amministratore del vCenter (se così non fosse, non potrete utilizzare il parametro -passthroughAuth nell’istruzione di seguito, ma sarete costretti al -u Administrator -p Password), questo è il comando che vi permetterà di lanciare un inventario e ottenere immediatamente l’elenco delle snapshot presenti sul vCenter:

rvtools -passthroughAuth -s $INDIRIZZOVCENTER -c ExportvSnapshot2xls -d C:\Temp -f vSnapshot.xls

Che potrà essere eseguito anche per esportare un file CSV, semplicemente modificando il tipo di chiamata e il nome del file di destinazione:

rvtools -passthroughAuth -s $INDIRIZZOVCENTER -c ExportvSnapshot2csv -d C:\Temp -f vSnapshot.csv

A tal proposito: il nome del file di destinazione non è obbligatorio. Omettendolo, il programma creerà autonomamente il file di output dandogli un nome di tipo standard, per esempio RVTools_export_all_yyyymmddhhmmss, ad indicare un export di tutte le informazioni, corredato poi dalla data odierna e dall’ora completa dell’avvio esportazione. In ogni caso, trovate tutti i tipi di chiamata diretta e informazioni aggiuntive nella documentazione ufficiale del programma, disponibile all’URL robware.net/download/RVTools.pdf.

Buon lavoro!

Condividi l'articolo con i tuoi contatti:

Powershell_512px-GWallFaccio riferimento a un vecchio articolo datato 2014, nel quale vi parlavo di uno script PS1 che avevo lasciato su un Domain Controller della rete per verificare l’utilizzo di una password errata per un determinato account di dominio. Quello script mi è tornato utile ancora una volta e oggi vi propongo il suo ultimo aggiornamento, in grado di monitorare il blocco dell’account di Active Directory, con conseguente mail di allerta a 3 diversi indirizzi di posta (mio e di due colleghi, in CC).

L’originale è ancora disponibile:

Powershell: Account di dominio bloccato o utilizzo di password errata? Mandami una mail con l’evento!

Cosa è cambiato?

L’ID dell’evento sotto monitor, come prima cosa: si tratta del 4740 e l’operazione pianificata si crea ancora alla stessa identica maniera, con l’eccezione del richiamo al prompt di PowerShell che ora utilizzo in maniera classica, passandogli poi parametri da riga di comando che vanno a richiamare il nuovo script:

Nel nuovo script è poi cambiato il testo della segnalazione che arriverà a mezzo mail, la parte commentata (per darle un aspetto migliore, nulla più) e il modo di inviare la mail ai destinatari, che mi permette così di utilizzare anche il -CC e la priorità (-Priority). Già messo alla prova, non fallisce un colpo, permettendo di diventare assolutamente reattivi nei confronti del monitorato “ACCOUNT_AD” (da modificare con l’utente che volete realmente tenere sotto controllo).

Come già detto, l’operazione pianificata sul server riguarderà l’evento 4740, il quale lancerà PowerShell passandogli come parametro lo script che nel frattempo avrete salvato in una cartella sul server (nel mio caso, C:\Script):

Ricordate che, in tutto questo, sarà necessario che la macchina sulla quale farete girare il file PS1 abbia la policy di esecuzione script non firmati, basterà lanciare (da PowerShell):

Set-ExecutionPolicy Unrestricted

e confermare la scelta quando vi verrà chiesto a video.

Con una ulteriore modifica, si potrebbe chiedere allo script di sbloccarlo automaticamente dopo un certo intervallo di tempo. Non l’ho volutamente ancora sviluppato perché non è la richiesta ricevuta, ma nessuno impedisce a voi di completare il quadro (e poi magari toccherà anche a me, probabilmente vi basterà attendere) :-)

Condividi l'articolo con i tuoi contatti:

Dalla nostra “arma di pubblicazione di massa” (tipicamente un PC, ma anche un tablet o altro mezzo più maneggevole) ai browser dei lettori, il passo è generalmente breve. Casa nostra, le nostre pattine, le nostre regole. Ma avete mai pensato al fatto che in realtà, nella maggior parte dei casi, le regole sono quelle che può (giustamente) imporre chi vi ospita al giusto prezzo? Molti blog là fuori (questo che state leggendo non fa eccezione) sfruttano offerte di hosting condiviso che offrono un pacchetto prestazionale corredato di spazio e banda entro un certo limite (ben dichiarato). Fare i conti con siti web ricchi di immagini e contenuti multimediali più in generale è d’obbligo, almeno dopo un primo giro di boa passato a fregarsene di ciò che si dà in pasto alla piattaforma (sbagliato, ma basta correggersi in corsa).

WordPress: suggerimenti sulla gestione delle immagini 3

Ho fatto i conti con Fuorigio.co, un contenitore fatto più da contenuti multimediali che da testi (o quasi). Si tratta di circa 16GB di installazione WordPress che certamente non tenderà a calare nel corso del futuro, in realtà tutto il contrario. Per questo motivo ho scelto di affidarmi ad alcuni metodi e plugin che ho potuto provare nel corso del tempo, oggi sono un po’ più pronto a parlarvene e realizzare un buon approfondimento per cominciare bene la settimana lavorativa.

La base di partenza

Sapete quanto occupa la vostra installazione WordPress? Ne avete una copia in locale per qualsiasi evenienza? Sono domande alle quali dovete poter dare una risposta abbastanza rapida, soprattutto in caso di problemi. Parliamo del mio caso. Circa 16 i GB sui quali ho cominciato a mettere le mani, da ottimizzare, GB sui quali (se possibile) fare un po’ di margine, guadagnare un po’ di spazio da poter utilizzare in seguito.

WordPress: suggerimenti sulla gestione delle immagini

Il problema? Presto detto: non possono esistere divari di occupazione disco tra le immagini proposte dal blog. Provo a rendere l’idea:

WordPress: suggerimenti sulla gestione delle immagini 1

39 MB per un singolo file immagine, magari proposto nella sua versione “Large” da 640px, non sono accettabili, è un totale spreco di risorse che ovviamente diventano sempre più preziose contestualmente al crescere del progetto. Una delle regole di base, una di quelle che si imparano già quando si muovono i primi passi, è quella di non effettuare upload di file multimediali che poi non vengono realmente utilizzati, sfruttati. Bisogna limitarsi nelle dimensioni (sia in fatto di pixel, sia in fatto di occupazione fisica). È una regola che occorre seguire e non sottovalutare, credetemi.

Cominciamo a rispondere alle prime domande, partendo dal presupposto che:

  • non bisognerà mettere in “pericolo” i file immagine precedentemente caricati, quasi certamente utilizzati all’interno dei vostri articoli,
  • prendere coscienza del fatto che difficilmente si potranno recuperare i file immagine caricati in origine, ma che se per caso li aveste, forse sarebbe il caso di ottimizzarli offline, ricaricarli su WordPress e sostituirli a quelli precedentemente caricati (quindi richiamarli negli articoli che ne facevano uso),
  • occorrerà sempre ridimensionare i file, cercando di non perdere la qualità (diversi sono gli strumenti a vostra disposizione).

Le soluzioni adottate

Il primo passo, fondamentale, è quello di avere una visione chiara e capire quali immagini occupano più spazio sul disco del server. Per farlo ho scelto il primo plugin di questo articolo, Media Files Tools, che tra le sue funzioni riporta un utilissimo “Add columns in Media Library: The new columns are File Size and MIME Type. The File Size column is sortable so you can find the files with the bigger size in an easy way.

Media Files Tools
Media Files Tools
Developer: j.conti
Price: Free

Cosa c’è da sapere: il plugin non calcola in real-time l’occupazione dei file immagine su disco, dovrete eseguire voi manualmente l’operazione (Dashboard → Media → File Tools → Get Files Size) e attendere pazientemente che termini (il tempo varia in base al numero di immagini presenti nell’installazione e RAM a disposizione sul server), verrà così popolata la colonna che riporta il valore di occupazione, per quello che mi riguarda, potete anche eliminare la colonna del MIME Type.

WordPress: suggerimenti sulla gestione delle immagini 4

Potrete ora mettere in ordine la colonna “File Size” per rendervi conto di chi occupa più spazio, così da iniziare a isolare i file sui quali occorrerà lavorare. Avrete quasi certamente notato (nell’immagine poco sopra) che ci sono due ulteriori colonne riguardanti lo spazio disco, più precisamente la compressione di ogni singolo file immagine. Si tratta della combinazione di due ulteriori plugin per il noto CMS, di cui uno a pagamento (dopo un certo numero di compressioni effettuate). Si tratta rispettivamente di “Compress JPEG & PNG images” e “EWWW Image Optimizer“:

Compress JPEG & PNG images
Compress JPEG & PNG images
Developer: TinyPNG
Price: Free
EWWW Image Optimizer
EWWW Image Optimizer
Developer: Shane Bishop
Price: Free

La compressione è uno step molto importante nel caso in cui a lavorare in Dashboard non sia una sola persona. Metodi di lavori differenti, abitudini differenti, un buon comportamento dovrebbe imporre di fare un giro di compressione in offline prima di procedere con l’upload su WordPress, spesso non accade, oppure accade ma non basta mai. Io utilizzo un paio di strumenti / metodi in base all’OS che utilizzo nello specifico momento, uno dei quali ve l’ho spiegato qualche tempo fa.

Brevemente, vi posso dire che:

  • Compress JPEG & PNG images è gratuito ma vi consente di effettuare 500 compressioni al mese, oltre le quali occorrerà pagare una piccola cifra per il numero di immagini compresse (oltre le 500), per esempio per 2000 immagini compresse si andrà a sborsare una cifra intorno ai 13$.
  • Compress JPEG & PNG images interviene durante l’upload dell’immagine nella Media Library. Si allungano i tempi di caricamento ma si accorciano quelli dei passaggi da eseguire, senza considerare lo spazio disco risparmiato. Nel caso in cui un’immagine non sia stata ottimizzata (per qualsivoglia problema), potrete intervenire direttamente dalla Media Library. Il plugin si integra infatti (come fa Media Files Tool) con le colonne proposte di default dal CMS.
  • Compress JPEG & PNG images permette il ridimensionamento dell’intera Libreria (un enorme bulk) o di un gruppo più ristretto di immagini, selezionabile dalla stessa Media Library di WordPress. Ci sono alcuni problemi, non è tutto rose e fiori, ho ancora un problema aperto con il supporto ma il software funziona bene, soprattutto se si vuole evitare di fare molti più passaggi, utilizzando manualmente il box di upload proposto sul sito web ufficiale (tinypng.com). Il loro algoritmo di ottimizzazione è molto buono, lo spazio che riescono a risparmiare senza rinunciare alla qualità è notevole.

e

  • EWWW Image Optimizer è gratuito, senza alcun limite di utilizzo. Permette di ottimizzare qualsiasi tipo di immagine e trasformare PNG in JPG (e viceversa). Si integra con NextGEN Gallery e GRAND FlAGallery. Utilizza algoritmi jpegtran, optipng/pngout e gifsicle. Lavorano bene, funzionano bene, il plugin svolge il suo lavoro ma non raggiunge gli ottimi risultati di TinyPNG.
  • Come per Media Files Tools, anche EWWW Image Optimizer si integra nelle colonne della Media Library di WordPress, permettendovi di ottimizzare la singola immagine, scegliere un bulk ristretto oppure mandare in ottimizzazione l’intera Media Library. Occhio però, quest’ultima scelta causerà quasi certamente il logoff forzato dalla Dashboard di WordPress, poiché l’hosting potrebbe prenderla male e pensare che si tratti di un’azione non lecita visto l’alto carico di lavoro per CPU e RAM.

Risparmiare spazio su disco e organizzare al meglio le immagini è un lavoro duro, che andrebbe portato avanti quotidianamente, un metodo da fare proprio più che altro. Prendere in mano le redini di un progetto mangia-spazio e riportarlo sui giusti binari è faticoso, ve lo assicuro. Ho salvato circa 6 GB di spazio disco che ovviamente verranno utilizzati in futuro, preziosissimi (pensate cosa vorrebbe dire un trasferimento su diverso provider o un backup full settimanale da FTP a dischi locali, cosa che già accade per la cronaca).

E se qualcosa dovesse cambiare?

Immaginate di aver inserito in campo un nuovo ridimensionamento immagini. Magari avete scelto di inserire una miniatura più piccola rispetto al passato, ulteriore spazio che è possibile salvare, non credete? E cosa si fa per ottenere tutti i nuovi ridimensionamenti? Ci si affida a Regenerate Thumbnails, plugin storico, ancora perfettamente funzionante:

Non vi preoccupate per la compatibilità, è ancora garantita nonostante nessuno lo dica su WordPress.org. Ancora una volta potrete scegliere di effettuare il ridimensionamento della singola immagine, del gruppo o dell’intera libreria:

WordPress: suggerimenti sulla gestione delle immagini 5

La velocità dell’operazione fa coppia con quanto detto già una manciata di righe fa: tutto dipende dalla quantità di immagini da cui ottenere le miniature, CPU e RAM a disposizione. Portate pazienza.

Tutto finito? Affatto, ho ancora un consiglio, questo è dedicato a coloro che rischiano di caricare mille volte le stesse immagini perché non trovano quelle desiderate tramite ricerca interna di WordPress. Succede spesso, soprattutto quando si tende a caricare file con nomi “non parlanti” (si suol dire così, per identificare immagini con sigle al posto di nomi facilmente ricercabili). Esiste un buon plugin anche in questo caso, si tratta di YoImages, che tra le varie sue funzioni di base riporta “images are important for SEO but are never optimized enough. With YoImages you can automatically optimize images for Search Engines. No more alt tag missing or non informative titles or file names. Google can’t see the image (yet) but, can read its attributes.“, andando così a mettere una pezza a un problema di tante installazioni, correggendo nomi non utili ai fini della ricerca (interna, ma anche da web, Google Images è solo un esempio), compilando automaticamente i tag di titolo e testo alternativo.

YoImages
YoImages
Developer: Sirulli
Price: Free

L’altra sua funzione principale (e fantastica, lasciatemelo dire) è quella di permettere un crop manuale delle immagini caricate, andando così a sostituire ciò che WordPress taglia di default e senza nostro consiglio o senso estetico: “no more images cropped wrong, you can choose now what to display and even replace the entire image for a specific crop size if the orginal image doesn’t fit. Crop at a lower quality to speed up page loading. Create croppings in retina format too.“. Potrete scegliere ogni singolo ridimensionamento, ottenendo crop in alta e bassa qualità per ogni utilizzo. Ha una terza funzione, forse meno importante (io l’ho personalmente disabilitata) ma pur sempre disponibile, e permette di ricercare immagini gratuite tramite splashbase.co e unsplash.com, caricarle nel nostro spazio disco e utilizzarle nell’editor di testo del proprio WordPress. È un plugin che funziona, lo fa molto bene. Non posso che consigliarlo.

Cosa manca?

L’ottimizzazione delle immagini fa parte di un più ampio lavoro, occorre rendere WordPress snello, rapido, deve poter rispondere in fretta e possibilmente senza sovraccaricare le risorse della macchina, database compreso. Anni fa ServerPlan aveva pubblicato un articolo che ritengo molto valido ancora oggi, basato sulla coppia DB Cache Reloaded Fix e WP Super Cache, questo l’articolo:

WordPress – Ottimizzazione, cache e moduli con problemi

Tocca a voi

Come gestite il vostro WordPress e i vostri contenuti multimediali? Avete consigli, suggerimenti o possibili correzioni rispetto alla mia esperienza? Siete i benvenuti, l’area commenti è a vostra totale disposizione, sarò felice di parlarne insieme :-)

Condividi l'articolo con i tuoi contatti: