Aldolat.it — Post con tag WordPress

Migrazione a Hugo

aldolat@gmail.com (Aldo Latino) — Sun, 24 Apr 2022 22:31:47 +0200

Da oggi questo blog non usa più WordPress, il CMS che lo ha accompagnato e servito per 16 anni. Da oggi il blog è costruito da Hugo, il framework per siti statici.

Grazie, WordPress, per il tantissimo che ho imparato usandoti.
Benvenuto, Hugo: la tua semplicità mi ha conquistato!

L'articolo Migrazione a Hugo è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Private Content 6.4.0

aldolat@gmail.com (Aldo Latino) — Sun, 28 Feb 2021 09:00:00 +0000

Ho rilasciato ieri la versione 6.4.0 del mio plugin per WordPress Private Content. Questo rilascio aggiunge la possibilità di mostrare una nota privata solo all’autore dell’articolo, quindi agendo in modo dinamico, senza doverne specificare il nome. La funzione è stata aggiunta a seguito della richiesta di un utente nel forum di WordPress, esattamente qui.

La nuova funzione si usa inserendo post-author nell’opzione role dello shortcode, per esempio:

[private role="post-author"]Text for the author of the post.[/private]

Con questo shortcode, solo l’autore del post e il ruolo Amministratore vedranno la nota privata.

Se invece si vuole escludere anche il ruolo Amministratore, bisognerà usare post-author-only, ad esempio:

[private role="post-author-only"]Text for the author of the post.[/private]

Come per gli altri casi, si può usare l’opzione alt per mostrare un testo alternativo per gli altri utenti, se si vuole.

Per avere una panoramica dei vari casi utilizzabili per l’opzione role ecco un’immagine, spero esplicativa:

Tra le varie versioni ho aggiunto il manuale del plugin in formato wiki e PDF, dove ho tentato di spiegarne l’uso. Entrambi sono disponibili su GitHub: qui il wiki e qui il PDF.

Una seconda novità introdotta da questa versione è il modo con cui il plugin costruisce le classe per il paragrafo che viene fuori. Come già sa chi usa questo plugin, con l’opzione class si possono specificare le classi personali da aggiungere al paragrafo. La novità è che ora gli eventuali underscore (_) saranno cambiati in trattini (-). Quindi, ad esempio, in questo schortcode:

[private class="myclass1, custom-class-2, my_class_3"]Private text.[/private]

la classe my_class_3 diverrà my-class-3.

Il plugin è disponibile nel repository di WordPress:

https://it.wordpress.org/plugins/private-content/

L'articolo Private Content 6.4.0 è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Search Regex 2.0

aldolat@gmail.com (Aldo Latino) — Sun, 10 May 2020 08:51:40 +0000

Finalmente, dopo 4 anni, Search Regex è stato aggiornato alla nuova versione 2.0. Ormai pensavo che questo plugin per WordPress fosse stato abbandonato, e invece eccolo qui vivo e vegeto e riscritto da zero (“a ground-up rewrite”, dal Changelog).

La versione 1.4.16 rilasciata il 28 marzo 2016.

Qui sopra la versione 1.4.16 rilasciata il 28 marzo 2016, qui sotto la versione 2.0 rilasciata proprio ieri.

La versione 2.0 rilasciata proprio ieri.

Grazie @johhny5, per il lavoro fatto!

L'articolo Search Regex 2.0 è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Contribuire a WordPress

aldolat@gmail.com (Aldo Latino) — Wed, 27 Nov 2019 08:51:40 +0000

https://www.youtube.com/watch?v=Mug9REZAuj0

L'articolo Contribuire a WordPress è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Aggiungere un menu di gestione rapida in WordPress

aldolat@gmail.com (Aldo Latino) — Sun, 17 Nov 2019 08:51:40 +0000

Quando ci capita di dover andare di continuo tra il front-end e alcune pagine di amministrazione del sito fatto con WordPress, che si trovano magari in sottomenu di qualche menu principale, ecco che tornerebbe utile avere nella barra degli strumenti, quella che sta in cima alle varie pagine, i collegamenti che ci servono di più. Nella figura qui sotto vedete il menu Gestione rapida, con alcune voci di più comune utilizzo.

Il menu Gestione rapida aggiunto alla barra del menu principale di WordPress.

WordPress ci consente di farlo grazie alle sue API. Come al solito, sarà necessario aggiungere una funzione al file functions.php del tema attualmente in uso (metodo sconsigliato) oppure al nostro plugin personalizzato (metodo consigliato), dove raccogliamo tutte le modifiche che ci servono anche quando cambiamo tema.

Ecco la funzione:

 1/**
 2 * Add a custom menu to the WordPress toolbar.
 3 *
 4 * @param object WP_Admin_Bar $admin_bar Core class used to implement the Toolbar API.
 5 */
 6function add_items_to_wordpress_toolbar( WP_Admin_Bar $admin_bar ) {
 7    // Stop the function if the current user cannot manage options.
 8    if ( ! current_user_can( 'manage_options' ) ) {
 9        return;
10    }
11 
12    // Create the root menu.
13    $admin_bar->add_menu(
14        array(
15            'id'    => 'rapid-management',
16            'title' => esc_html__( 'Rapid Management', 'text-domain' ),
17            'href'  => admin_url( '#' ),
18            'meta'  => array(
19                'title'  => esc_html__( 'Rapid Management', 'text-domain' ),
20                'target' => '_self',
21                'class'  => 'rm-root-menu',
22            ),
23        )
24    );
25 
26    // Add the first menu item.
27    $admin_bar->add_menu(
28        array(
29            'id'     => 'rapid-management-posts',
30            'parent' => 'rapid-management',
31            'title'  => esc_html__( 'Posts', 'text-domain' ),
32            'href'   => admin_url( 'edit.php' ),
33            'meta'   => array(
34                'title'  => __( 'Edit posts', 'text-domain' ),
35                'target' => '_self',
36                'class'  => 'rm-posts',
37            ),
38        )
39    );
40 
41    // Add the second menu item.
42    $admin_bar->add_menu(
43        array(
44            'id'     => 'rapid-management-pages',
45            'parent' => 'rapid-management',
46            'title'  => esc_html__( 'Pages', 'text-domain' ),
47            'href'   => admin_url( 'edit.php?post_type=page' ),
48            'meta'   => array(
49                'title'  => esc_html__( 'Edit pages', 'text-domain' ),
50                'target' => '_self',
51                'class'  => 'rm-pages',
52            ),
53        )
54    );
55 
56    // Add other items here...
57}
58 
59add_action( 'admin_bar_menu', 'add_items_to_wordpress_toolbar', 100 );

Potete aggiungere tutti i link che volete al posto della riga // Add other items here.... Vanno chiaramente adattate le righe, modificando ID, title, ecc.

L'articolo Aggiungere un menu di gestione rapida in WordPress è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Quando il nome del tuo plugin non aiuta

aldolat@gmail.com (Aldo Latino) — Sun, 17 Nov 2019 08:51:40 +0000

Chi segue questo blog magari si ricorderà che nel 2010 creai un plugin per mostrare una porzione del testo di un articolo o di una pagina solo a determinati ruoli di WordPress. Quel plugin, che creai a maggio del 2010 e resi disponibile al download dal sito digwp.com di Jeff Starr, è nei repository di WordPress da novembre del 2012.

Questo plugin si chiama Private Content. Un nome come un altro, ma purtroppo si è rivelato nel tempo eccessivamente semplice da usare per altri sviluppatori di plugin. Quantomeno nel repository di WordPress ce n’è uno che si chiama WP Private Content Plus e, nel repository di CodeCanyon, uno che ha lo stesso identico nome del mio, cioè Private Content, appunto.

Questa cosa ha causato negli anni, compreso oggi, non poche noie, sia a me che agli utenti. Cominciamo dall’ultimo plugin, quello ospitato su CodeCanyon.

Private Content su codecanyon.net

Avendo questo plugin lo stesso identico nome del mio, succede che agli utenti del plugin di CodeCanyon — quando io pubblico un aggiornamento — WordPress sovrascrive la directory del plugin installato con quella del mio plugin.

In altre parole, se un utente usa Private Content di CodeCanyon e io pubblico un aggiornamento del mio plugin (che è tutto un altro plugin), WordPress gli installa il mio, con tutti i problemi che potete immaginare.

Il plugin ospitato su CodeCanyon gestisce tutta una serie di funzioni (tra cui, se ho capito bene, autenticazione degli utenti, visibilità di contenuti a pagamento e cose simili), col risultato che, in caso di sovrascrittura del plugin legittimo, l’amministratore si ritrova con un plugin del tutto diverso e una situazione completamente sottosopra: dopo essersene accorto, dovrà ripristinare la situazione subito, altrimenti addio a tutti i permessi che aveva impostato.

Com’è possibile che succeda questo? WordPress (almeno per ora) non ha una gestione dei plugin basata su firma crittografica, hash o tecniche di questo tipo, ma si basa, per aggiornare un plugin, sullo slug del plugin, slug che coincide col nome della directory dove viene ospitato sul suo repository. Quindi, se nel sito dell’utente la directory che contiene il plugin di CodeCanyon si chiama private-content e WordPress si accorge che il plugin Private Content fatto da Aldo (che ha lo stesso slug private-content) è stato aggiornato rispetto a quello installato, WordPress lo “aggiorna”, sostituendo il contenuto della directory.

Ho perso il conto di quanti utenti mi hanno segnalato questa cosa, ma non posso farci niente. Avrei dovuto, semmai, scegliere un nome più complicato, ma non era semplice immaginarsi una cosa di questo tipo.

WP Private Content Pro su wordpress.org

La storia con questo plugin è invece recentissima. Non mi era mai capitato di imbattermi in problemi con lui.

Oggi, di prima mattina, insieme col caffè mi arriva la segnalazione che un utente ha lasciato una recensione a una stella su questo plugin. Apro la recensione e leggo:

Easily infected! Addirittura! 😀 Ho notato subito, però, quel wppcp_options che il mio plugin non crea assolutamente nel database. Immediatamente ho capito che si trattava di un’altro scambio di plugin: l’autore della recensione, mi sono detto, ha sbagliato posto.

Cerco subito quale plugin possa creare quell’option name nella tabella delle opzioni di WordPress. Non mi ci è voluto molto a trovare il plugin WP Private Content Plus (notate il prefisso del nome delle opzioni wppcp_ che combacia con questo nome). Ho anche notato che nelle recensioni di questo plugin diversi utenti hanno segnalato (scorrettamente, perché non si fa così) problemi di sicurezza di questo plugin, ormai risolti a detta del suo autore.

Ho fatto presente all’autore della recensione l’errore:

Ho atteso quasi tutto il giorno. Nel tardo pomeriggio ho aggiunto un altro commento alla recensione, ma questa volta rivolgendomi ai moderatori e aggiungendo alla recensione il tag modlook, fondamentale per far intervenire i moderatori:

Pochi minuti dopo, un moderatore è intervenuto e, dopo aver lasciato un commento, ha cancellato la recensione. Ecco cosa ha scritto:

@xxxyyyzzz

It appears you’ve posted this incorrectly so I’m removing it.

Reviews are not how you should deal with a potentially vulnerable plugin. Please see https://developer.wordpress.org/plugins/wordpress-org/plugin-security/reporting-plugin-security-issues/ for the proper procedure.

Steve Stern, su wordpress.org

Il punto 1 era palese: il recensore si era sbagliato sulla pagina dove scrivere. Il punto 2 è interessante perché tiene conto della responsible disclosure: detto in breve, se trovi una vulnerabilità, non spiattellarla subito ai quatto venti, ma avvisa in privato chi di competenza e dai un tempo massimo per la risoluzione del problema, al cui scadere renderai pubblica la vulnerabilità.

Poco fa l’autore della recensione si è scusato via email e mi ha anche ringraziato per averlo guidato.

Ecco, tutto questo per dire che, se avessi usato un nome del tutto diverso da Private Content, di certo in questi anni non avrei dovuto perdere tempo dietro a queste storie.

L'articolo Quando il nome del tuo plugin non aiuta è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Una pezza per SyntaxHighlighter

aldolat@gmail.com (Aldo Latino) — Sat, 19 Jan 2019 20:21:19 +0000

Con una funzione molto semplice è possibile mettere una pezza al problema del plugin SyntaxHighlighter, che segnalavo qui.

Grazie a @kaggdesign per la condivisione.

L'articolo Una pezza per SyntaxHighlighter è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

WordPress 5, SyntaxHighlighter Evolved e il carattere «&»

aldolat@gmail.com (Aldo Latino) — Wed, 09 Jan 2019 18:24:17 +0000

C’è attualmente un problema, confermato da Alex Mills, a.k.a. @viper007bond, circa il corretto escaping del carattere & in WordPress. Trovate la mia discussione con Alex nel forum di WordPress.

Dalle mie prove sembrerebbe che il problema si presenti solo nei pezzi di codice pubblicati in un post usando il plugin SyntaxHighlighter Evolved. Ad esempio:

Qui ho usato il blocco standard di WordPress per il codice e il carattere è correttamente mostrato.

Qui, invece, usando il blocco del plugin SyntaxHighlighter Evolved, no.

Alex ha aperto un ticket su Github in quanto dipenderebbe da WordPress.

L'articolo WordPress 5, SyntaxHighlighter Evolved e il carattere «&» è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Facciamo il punto sul mio plugin “Posts in Sidebar”

aldolat@gmail.com (Aldo Latino) — Sun, 06 Jan 2019 09:30:39 +0000

L’ultima volta che ho scritto di Posts in Sidebar è stato il 2 giugno 2013 e, da allora, sono stati fatti tanti rilasci di questo mio plugin. Tante ore spese a scrivere codice, fare debug e dare assistenza nel forum. Nato da un’esigenza puramente personale, il plugin venne pubblicato perché era giusto consentire ad altri di poterne trarre qualche vantaggio e, a quanto pare, viene usato da un po’ di utenti.

Dalla versione 1.7, di cui scrivevo appunto nel giugno 2013, siamo arrivati alla versione 4.7.3. Il plugin è cambiato parecchio e tante funzioni sono state aggiunte: diciamo che l’oggetto WP_Query è abbastanza “alla portata di widget”. Dalla galleria di foto qui sotto (fare clic per ingrandire l’immagine) si vede come il plugin sia cresciuto: nella versione 1.0 le opzioni stanno tutte su una schermata, come anche nella successiva 1.7 anche se aumentate, mentre nell’attuale 4.7.3 sono cresciute a dismisura tanto che stanno quasi tutte racchiuse dentro pannelli e sottopannelli (ogni box verde è un pannello che si espande e si contrae con un clic):

Il pannello delle opzioni di Posts in Sidebar 1.0.

Il pannello delle opzioni di Posts in Sidebar 1.7.

Il pannello delle opzioni di Posts in Sidebar 4.7.3.

A cosa serve questo plugin

I sottopannelli dedicati alla personalizzazione della query.

Questo plugin serve a mostrare nella sidebar alcuni post scelti secondo determinati criteri. Ad esempio:

mostrare gli ultimi post;
mostrare gli ultimi post pubblicati in una o più categorie o in uno o più tag;
mostrare post a caso;
mostrare post a caso ma aventi certe tassonomie (categorie, tag, formati di post, ecc.);
mostrare post con un certo stato (pubblicato, programmato, bozza, in attesa di revisione, ecc.);
mostrare post di un certo autore;
mostrare post con determinati campi personalizzati;
mostrare post pubblicati in certi intervalli di date;
mostrare post risultanti da una ricerca;
mostrare post mediante query complesse di tassonomie;
mostrare un determinato gruppo di post in tutte le pagine e, invece, i post dell’autore dell’articolo corrente quando si visualizza un articolo singolo;
mostrare i post di una delle categorie del post quando si visualizza un articolo singolo;
e altro ancora.

Oltre a ciò è possibile scegliere cosa visualizzare del post: oltre al titolo, si può scegliere se mostrare anche un estratto (o un altro tipo di testo); si può mostrare l’immagine in evidenza, le categorie, i tag, le tassonomie personalizzate, la data, ecc.

Il prezzo di questo plugin

Posts in Sidebar è distribuito gratuitamente nel repository di WordPress ed è pubblicato sotto licenza GPL v3. Chi ha pagato tanto in termini di tempo e fatica sono io, ma l’ho fatto divertendomi. Quando, a volte, in alcune applicazioni disponibili sulla rete vedo la riga che dice Made with love in California (o altrove), ecco ritengo che sia molto vero se penso alla mia esperienza di lavoro sui miei plugin. 🙂

L’assistenza nel forum

Uno dei punti cardine dello sviluppo di Posts in Sidebar è stato il mio rapporto con gli utenti nel forum. Sempre rispettosi dello sviluppatore del plugin, mi hanno chiesto assistenza nell’uso ma soprattutto nell’adattamento dell’aspetto alla grafica del tema. Il plugin, infatti, non ha una grafica sua e visualizza i post senza interporre nulla a livello di CSS (se non quando esplicitamente si attivano alcune opzioni dedicate). Spessissimo mi hanno anche chiesto assistenza su cose che esulavano del tutto dal plugin, ma non mi sono tirato indietro e non li ho mai liquidati con risposte sbrigative, cercando invece di immedesimarmi e di dar loro il supporto richiesto.

Il widget che questo plugin genera è stracarico di opzioni. Molte le ho aggiunte io, nel tentativo di rendere facilmente disponibile a tutti la potenza di WP_Query, ma molte opzioni nascono nascono proprio da loro richieste. A memoria mia credo di averne respinte poche, perché le reputavo interessanti e utili per altri eventuali utenti.

Il futuro dello sviluppo

Ad oggi non ho molto da aggiungere al plugin, perché credo di essere molto vicino al traguardo che mi ero prefissato: poter estrarre i post desiderati dal database e mostrarli in un widget.

A livello di scrittura del codice confesso che mi sarebbe piaciuto programmarlo ad oggetti, ma non ho mai avuto il tempo di imparare. Non programmo per mestiere e guardando il codice si vede, ma oltre non potevo andare.

L'articolo Facciamo il punto sul mio plugin “Posts in Sidebar” è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

WordPress e l’attributo rel del tag HTML link

aldolat@gmail.com (Aldo Latino) — Sat, 05 Jan 2019 21:13:53 +0000

Mentre stavo leggendo quali sono i meta tag HTML considerati da Google nell’indicizzazione delle pagine, mi sono imbattuto nell’articolo correlato Indicare a Google i contenuti suddivisi in più pagine. Siccome ho qualche articolo suddiviso in più pagine, come questo, ho voluto verificare se e come sono inseriti questi tag nel codice.

E ho notato qualcosa di strano.

Un ripasso veloce

L’attributo rel="next" e rel="prev" per il tag HTML <link> inserito nel tag <head> va usato per indicare che la pagina che si sta leggendo fa parte di un articolo unico suddiviso in più pagine. Il W3C definisce next così:

The next keyword indicates that the document is part of a sequence, and that the link is leading to the document that is the next logical document in the sequence.

W3C, Link type “next”.

mentre per prev dice:

The prev keyword indicates that the document is part of a sequence, and that the link is leading to the document that is the previous logical document in the sequence.

W3c, Link type “prev”.

Per cui, se un articolo è suddiviso in 5 parti e stiamo leggendo la pagina 1 della serie, il tag <link> sarà così:

<link rel="next" href="http://www.example.com/parte-2" />

mentre nella pagina 2 avremo:

<link rel="prev" href="http://www.example.com/parte-1" /> <link rel="next" href="http://www.example.com/parte-3" />

e nell’ultima:

<link rel="prev" href="http://www.example.com/parte-4" />

Cosa ho notato

E veniamo ora al punto. Ho scoperto che WordPress non usa in modo corretto questo attributo, in quanto lo usa per indicare il post precedente e il post successivo a quello che si sta leggendo. Ad ogni modo è possibile intervenire per ripristinare l’uso corretto del tag <link>.

Non ho verificato se esiste un ticket su questa cosa, ma comunque ho cercato se qualcuno si fosse già accorto del problema. Tra i risultati vi segnalo questo post, da cui ho tratto ispirazione per il mio articolo e in parte per la funzione che vi propongo sotto. Vi voglio evidenziare questo passaggio di quanto scrive l’autore:

Currently (version 4.2.2), wordpress already adds a rel=“prev” and rel=“next” tag to single posts, but these tags are added to all posts irrespective of whether they have pagination or not. And oddly enough, the pages that have pagination do not have these tags. Having these tags on non-paginated posts makes little to no sense from the SEO perspective and it only serves as additional clutter you can get rid of.

Mukesh M, Adding Rel=“Next” And Rel=“Prev” Tags To Paginated Single Posts (Using NextPage Tag).

Rimozione del tag <link> di WordPress

Se avete un plugin personale con le funzioni che vi trascinate dietro anche quanto cambiate tema, inserite la seguente riga:

remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );

Se non avete questo tipo di plugin, inseritela nel file functions.php del tema in uso.

Aggiunta del tag <link> corretto

Aggiungiamo ora la funzione che utilizza in modo corretto il tag <link> e il suo attributo rel="next" e rel="prev" solo quando il post o la pagina sono suddivisi in più pezzi.

Aggiungete le righe seguenti al plugin personale o al file functions.php del tema. Il codice è abbastanza commentato.

 1/**
 2 * Prints the HTML tags link rel prev and next in the header.
 3 *
 4 * The attributes prev and next for the HTML tags link in the header
 5 * must be used when an article in divided into multiple pieces, so that the
 6 * first page has a link tag to the second part, the second page has a link
 7 * to the previous part and to the following part, the last page has a link
 8 * to the previous part.
 9 *
10 * WordPress uses incorrectly these tags to link the current post to the previous
11 * and the following posts, as if all the published posts belong to a single big article.
12 *
13 * @link https://support.google.com/webmasters/answer/1663744?hl=it&ref_topic=4617741
14 * @global object $wp_query The WP_Query object.
15 */
16function add_link_tag_header() {
17    // Get the global variable $wp_query, which will be used later.
18    global $wp_query;
19
20    // Figure out if we have a paginated post/page and count them.
21    $total_pages = count( explode( '<!--nextpage-->', $wp_query->post->post_content ) );
22
23    // If we are in a post/page and the total number of pages is greater than 1.
24    if ( is_singular() && 1 < $total_pages ) {
25        // Get the current number of page.
26        $current_page = intval( get_query_var( 'page' ) );
27
28        // If we are in the first page, change the number to 1 (in an array, the first element has number = 0).
29        if ( 0 === $current_page ) {
30            $current_page = 1;
31        }
32
33        echo "\n\n" . '<!-- Function: add_link_tag_header() -->' . "\n";
34
35        // Add prev HTML link tag.
36        if ( $current_page > 1 && $current_page <= $total_pages ) {
37            echo '<link rel="prev" href="' . esc_url( trailingslashit( get_permalink() . ( $current_page - 1 ) ) ) . '" />' . "\n";
38        }
39
40        // Add next HTML link tag.
41        if ( $current_page >= 1 && $current_page < $total_pages ) {
42            echo '<link rel="next" href="' . esc_url( trailingslashit( get_permalink() . ( $current_page + 1 ) ) ) . '" />' . "\n";
43        }
44
45        echo '<!-- Function: add_link_tag_header() -->' . "\n\n";
46    }
47}
48add_action( 'wp_head', 'add_link_tag_header' );</code>

Una volta messa in opera la modifica, alla pagina 6 di un articolo di 10 pagine avremo all’interno dal tag <head> qualcosa di questo tipo:

<!-- Function: add_link_tag_header() -->
<link rel="prev" href="https://www.example.com/titolo-del-post/5/" />
<link rel="next" href="https://www.example.com/titolo-del-post/7/" />
<!-- Function: add_link_tag_header() -->

Tutto questo in attesa che gli sviluppatori di WordPress sistemino la cosa.

L'articolo WordPress e l’attributo rel del tag HTML link è uno scritto di aldolat.it. Rispettane le condizioni di licenza.