WordPress 4.3 beta1

Ieri è stata rilasciata la prima beta del nuovo ciclo di sviluppo relativo a WordPress 4.3

Come al solito parecchie le novità:

  1. I menu posso essere gestiti anche tramite il customizer (se il template lo supporta). Ormai la tendenza è qualla di rendere modificabile ogni aspetto direttamente dell’anteprima del template. Per chi non avesse ancora avuto modo di provarlo anche lato codice e di itegrarlo nel proprio template posso dire che è molto semplice.
  2. Gestione integrata da admin della favicon
    Dal menu “impostazioni” e poi “generale” dopo titolo e motto troviamo la “site icon“.
    Questi i 3 link attualmente gestiti di default dall’hook generato con wp_head

    <link rel="icon" href="favicon-32x32.jpg" sizes="32x32" />
    <link rel="apple-touch-icon-precomposed" href="favicon-180x180.jpg">
    <meta name="msapplication-TileImage" content="favicon-270x270.jpg">

    wordpress-favicon

  3. Un grosso miglioramento nella gestione e generazione delle password utente (che non verranno più inviate via mail).
    Per chi vorrà continuare ad usare delle non-password come giulia-82, matrix o 123password dovrà anche spuntare un checkbox prima di poter salvare.wordpress-password-generator
  4. Aggiunto supporto all’editor visuale per alcune sintassi tipiche del Markdown
    Tutte cose che si potevano fare anche attraverso i pulsanti presenti sopra l’editor ma per chi è abituato ad usare Markdown potrà beneficiarne sopratutto in termini di velocità.
    Le sintassi supportate sono:

    • “## nome titolo” per gli h2 (da h2 ad h6)
    • “> testo indentato” per generare un blockquote
    • “- elenco non numero” per generare un tag ul
    • “1) elenco ordinato” per generare un tag ol

    (provatelo che è più semplice a farlo che a spiegarlo)
    wordpress-tinymce-markdown

  5. Migliorato il comportamento responsivo nelle pagine di elenco post (tutte quelle gestite tramite la classe wp_list_table).
    Per chi usa tabblet, smartphone e/o device a bassa risoluzione sarà un miglioramento sicuramente molto comodo in termini di usabilità.wordpress-responsive-admin-table

Anche per gli sviluppatori ci sono un po’ di cose tra cui la suddivisione dei termini nel caso siano presenti in più tassonomie e l’introduzione di “singular.php” nella gestione della gerarchia delle pagine nel caso non siano preseti “post.php” e “page.php”

Se siete in zona ne parliamo dal vito il 14 luglio al WordPress Meetup Torino

 

 

 

 

WordPress: Visualizzare solo i “contenuti” di cui si è autore

Nelle situazioni in cui più persone partecipano alla preparazione degli articoli sullo stesso sito a volte ci si trova davanti ad una grande quantita di contenuti in cui si fatica a filtrare le proprie bozze.

Quando necessario, per semplificare le cose, aggiungo questa piccola funzione che filtra post, pagine e Custom Post Type sulla base dell’utente loggato verificando 3 cose:

  1. se non faccio parte del gruppo “administrator” (gli admin continueranno e vedere tutti i contenuti)
  2. se sono in area di amministrazione
  3. se non sono nella pagina dei media (in modo che possa vedere tutte le foto caricate)

L’hook usato è il “pre_get_posts” che ci permette di aggiungere una condizione prima di effettuare la query rendendo il tutto molto più performante.

Queste poche righe vanno aggiunte nel file function.php oppure linkate tramite un include o require.

WordPress: cambiare il permalink della ricerca

Questo è un’altro degli snippets che uso normalmente sui template WordPress che mi chiedono di sviluppare.
Il primo pezzo (template_redirect) si occupa semplicemente di modificare il permalink base delle ricerca da “http://www.nomesito.com/?s=query” a “http://www.nomesito.com/search/query/“.

Con il secondo gestisco il caso in cui NON voglio che la keyword usata per la ricerca sia “search“.
Vado quidi a modificare la “search_base” ed a creare la regola di rewrite.
Ovviamente è necessario rigenerare i permalink in modo che la regola venga gestita correttamente.

Mark Jaquith aveva scritto anche un plugin ma oltre al fatto che non gestiva la modifica della “search_base” preferisco gestirlo via codice includendolo dimanicamente dentro functions.php

WordPress: Area riservata

In molti casi è necessario riservare l’accesso ad alcuni contenuti solo agli utenti loggati e senza ricorre ad ulteriori plugin io solitamente implemento un template di pagina che verifica che l’utente corrente sia correttamente loggato.

Questo un veloce esempio:

I più attenti potrebbero dirmi che per una cosa del genere basterebbe impostare la visibilità della pagina come “privata” ma in questo modo abbiamo il vantaggio di poter personalizzare anche l’aspetto della pagina usando un menu ed una sidebar su misura per miglioare l’esperienza utente.

Lo stessa tecnica si può applicare anche ad interi CPT semplicemente eliminado la riga relativa al nome del template e modificando il nome del file in questo modo:

single-{nome_post_type}.php

Ricordatevi però che in questo modo i contenuti continueranno ad essere elencati sia negli archivi che nella ricerca di default di WordPress, sarebbe quindi oppurtuno preparare un contenuto di default anche per il campo riassunto (excerpt) e gestire i listing in modo opportuno.

WordPress: Aggiungere campi per profilo facebook e twitter agli utenti

In molti siti, al fondo degli articoli, quando il template lo supporta è presente un box con i dati dell’autore che lo ha scritto.

Queste informazioni vengono prese dalla pagina di pagina di profilo utente che di default prevede nome, mail, sitoweb e descrizione, per l’avatar in genere viene usato il servizio offerto da Gravatar (che è un’altro dei tanti servizi Automattic) ma per la gestione dei link ai profili social dobbiamo fare un po’ di lavoro.

Questa la mia soluzione:

add_filter('user_contactmethods', function ($profile_fields) {
// Nuovi campi
$profile_fields['twitter'] = 'Twitter ';
$profile_fields['facebook'] = 'Facebook ';
$profile_fields['gplus'] = 'Google Plus';
// Remove old fields
unset($profile_fields['aim']);
return $profile_fields;
});

Per leggerle è semplicissimo:

get_the_author_meta('twitter')

Questo il risultato su uno dei miei ultimi lavori:
user-bio

Rispetto all’utilizzo di un plugin rimane ovviamente molto più leggero e ci permette di integrare il tutto all’interno del nostro template.

Usare JetPack anche sviluppando in locale

Per chi ancora non lo conosce JetPack è un plugin sviluppato direttamente da Automattic che raccoglie al suo interno diversi moduli. Attivabili o meno a bisogno.

Al momento (maggio 2015) sono presenti 35 moduli tra cui:

Il problema è che usare alcuni di questi moduli è necessaria una connessione ad internet e sopratutto l’autenticazione attraverso WordPress.com

Non però sempre è possibile sopratutto se si lavora in locale per sviluppare.

La soluzione è questo filtro che attiva la “development mode” (e che quindi non richide ne auteticazione ne connessione ad internet)

add_filter( 'jetpack_development_mode', '__return_true' );

Purtroppo in questo modo non tutti i moduli saranno attivi in quando alcuni per funzionare richiedono dati a server esterni (ad esempio Omnisearch, Related Posts).

Personalmente sono stato molto scettico sull’utilizzo di questo plugin ma vista la qualità del codice con cui è stato scritto e la quantità di funzionalità lo propongo sempre più spesso.

“mysql has gone away” durante importazione

Da pochi giorni ho cambiato notebook e un pezzo alla volta sto migrando tutto sul nuovo sistema.
Tra le tante cose da portare avevo anche i database dei progetti dei quali ho fatto sviluppo in locale.

Ho deciso di esportarli tutti con un’unico dump e fin qui tutto bene (circa 1gb di dati):
mysqldump -u root -p --all-databases > alldb.sql

Trasferisco da un macchina all’altra e quando provo ad importarli ricevo un bellissimo: mysql has gone away.

mysql-has-gone-away

Ricordo che in passato avevo avuto un problema simile che avevo risolto modificando il timeout.
Breve ricerca su google e aggiungo queste 3 righe nel file di configurazione impostando i valori ben oltre i valori di default.


wait_timeout = 128800
connect_timeout = 120
interactive_timeout = 128800

Il risultato non cambia: mysql has gone away.
Aumento ancora ma nulla…

Prendo in considerazione di esportare i database uno alla volta ma sono più di 50 e non ne ho voglia…

Ricontrollo l’errore e vedo che si ferma sempre alla stessa riga.
Apro il dump e vado a vedere: si tratta di una INSERT multipla molto (molto) lunga.

Scorro le altre variabili presenti nel file di configurazione ed ecco davanti a me la causa del problema:
max_allowed_packet = 1M

Questa variabile globale imposta la dimensione massima dei pacchetti e nel mio caso era troppo piccola per quella query estramamente grossa.
La porto da 1 a 5M, riavvio il servizio e lancio l’importazione che questa volta arriva al fondo senza problemi.

La prossima votla spero di ricordami di aver scritto qui la soluzione…

Illustrazione di Elena Triolo

WordPress e qualità: sistemi di cache manuali

Per parlare di qualità, tra le tante cose, si devono definire requisiti ed obiettivi e poi trovare degli indicatori per poterli misurare.
Io sto cercando di intrudurre una serie di linee quida nel mio modo di sviluppare ad una di queste si riferisce alla velocità ed al numero di query con cui vengono generate le pagine.

 

Gli indicatori che mi danno la misura e mi permettono di capire se sto rispettando i miei requisiti sono di tre tipi:

  1. Lato browser: YSlow, Page Speed ma anche il pannello “Net ” di Firebug. Con questi verifico i tempi di caricamento dei singoli componenti della pagina ed eventuali colli di bottiglia nel caricamento di js.
  2. Lato server: XHProf . Si tratta di un profiler gerarchico per verificare i tempi di esecuzione di ogni singola funzione.
  3. Lato WordPress: Debug Query e Debug Object. Tramite questi plugin ho sotto controllo il numero di query ed un dettaglio dei singoli oggetti interni a WordPress.

E’ ovvio che uno dei primi livelli di ottimizzazione sia l’intruduzione dei sistemi di cache.
Un uso appropriato può farci risparmiare diverse query e parecchi ciclo di CPU ma dato che in molti hanno già parlato dei plugin che possono aiutarci nella gestione “semiautomatica” della cache vado oltre e vi segnalo solo un articolo fatto da qualcuno che si è anche preoccupato di andare un po’ più a fondo preparando qualche test.

Continue reading “WordPress e qualità: sistemi di cache manuali”

DrupalCamp Torino 2010 ed il modulo Solr

Che sabato scorso sia andato a sentirmi qualche speech al DrupalCamp l’ho già detto, ma voglio ancora appuntarmi un paio di cose interssanti che ho sentito a che mi piacerebbe approfondire.

Bello il talk di presentazione fatto da horncologne che mi ha dato una visione più completa sulle caratteristiche e funzionalità di Drupal (di cui spero di poter recuparere le slide) ed interessante l’approccio al salvataggio delle configurazione su file, ma quello che mi ha “illuminato” è stato il talk su Solr. (In verità il talk era sul modulo per drupal che ne permette l’interfacciamento questo è un dettaglio… )

Di Solr ne avevo solo sentito parlare ma a suo tempo non ne avevo capito le potenzionalità ed in quali contesti poterlo sfruttare.

Penso che il progetto Apache Solr possa essere definito come un “motore di ricerca” al quale dare in pasto dei dati e che dopo averlo messo nelle condizioni di indicizzarle è in grado di poter restituire i risultati con delle logiche complesse che nulla hanno a vedere con una serie di “select from where”.

Oggi, dopo aver letto qualche documento, ho le idee decisamente più chiare e spero a breve di poterlo utilizzare in un progetto che è in fase di definizione e che potrebbe essere un’ottima occasione per approfondere le problematiche relative alla sua installazione ed alla sua configurazione.

L’interfacciamento in questo caso andrebbe fatto con un applicazione custom che viene valorizzata tramite un plugin per WordPress presente lato amministrazione ma le logiche di hook per l’invio dei dati sarebbero simili a quelle presenti nel modulo Drupal.

Se qualcuno avesse avuto esperienze simili e volesse aiutarmi a fare un plugin “wp-solr” sappia che è il benvenuto…

WordPress è meglio di Drupal

A dirlo non sono io ma Jennifer Lea Lampton durante la DrupalCon di Copenaghen lo scorso 23 Agosto.


Ma andiamo con ordine:
Sabato scorso sono stato al DrupalCamp di Torino (spendida location) e durante il talk di Jeffrey McGuire è stato segnalato un intervento molto “provocatorio” preparato da questa Jennifer che come potete vedere dalle sue esperienze non credo possa considerarsi una “fanboy” di WordPress.

Qui sotto le slide che danno una chiara idea del suo talk:

Sono convito che il tutto vada letto con spirito critico e come diceva anche Mizi in un commento su FriendFeed sono prodotti diversi con target diversi.

WordPress è una piattaforma che ha sicuramente molti margini di miglioramento sopratutto nell’implementazione del suo core e nell’ottimizzazione delle performance ma penso che a questo punto non sia più giusto considerarlo come un giocattolo ad uso esclusivo dei webdesigner.

update:
per chi vuole partecipare è partita un’interessante discussione su FriendFeed

Di WordPress e di professionalità

Con il tempo ho deciso di smettere di reinventare l’acqua calda e di riscrivere pezzi di codice che sicuramente altri hanno scritto meglio di me e dopo essermi guardato un po’ attorno sperimentando diverse soluzioni ho scelto di concentrarmi e di specializzarmi su WordPress

Questo cappello per dirvi che leggendo alcuni commenti a questo sondaggio mi sono un po’ “stupito”…

  • Stupito di aver trovato web-designers che preferiscono scrivere codice “from scratch” piuttosto che usare framework sviluppati, debuggati e mantenuti da solide community
  • Stupito di aver letto di gente che “a prescidere dal contesto” pensa che a far tutto da se ci sia più libertà di movimento
  • Stupito di aver constatato l’esistenza di “sviluppatori” in grado di affermare che usare un CMS non basta per un sito professionale

Ora io sicuamente sarei di parte se vi elencassi una serie di siti che potrebbero essere presi come esempio e che usano WordPress, quindi vi lascerò analizzare questi dati senza commetarli.

Se poi vi state chiedendo come sia riuscito un sempliceblog engine” ad essere il primo in questo elenco potete dare un’occhiata a questa infografica sulla diffusione di WordPress.

Per quanto mi riguarda ci sono poi anche delle motivazioni che accrescono la stima che ho nelle persone che fanno parte di Automatic come ad esempio il fatto che abbiano trasferito il marchioWordPress” alla fondazione no-profit, mentre altre mi riempiono di soddisfazione come quella in cui Microsoft decide di adottare WordPress come piattaforma di blog predefiniata per Windows Live

Chiudo con una cosa che ultimamente mi capita di dire pittosto spesso: “WordPress è uno strumento molto semplice da usare ma è altrettanto semplice usarlo male (plugin e template compresi).”
Questo per dire che sta al singolo webdesign e/o sviluppatore fare le cose al meglio.