Attributi blocchi Gutenberg: ritornano ‘undefined’ se la fonte sono i post meta

, ,

EDIT DEL 10 GIUGNO 2019: Il motivo principale per cui ciò accadava era perchè i register_meta venivano chiamati all’interno di un file che veniva caricato solo nel backend. Rendendoli disponibili anche in front funziona tutto a dovere.

Lavorando nella creazione di nuovi blocchi per il mio plugin Yasr, ho perso quasi due pomeriggi interi su quello che poi ho scoperto essere un bug di Gutenberg , (il link è al duplicato, ma credo che vada più diretto al punto) che purtroppo ho scoperto solo dopo che avevo già realizzato il mio workaround: l’ho trovato infatti quando stavo creando una nuova issue su GitHub.

Andiamo con ordine: avevo bisogno di pescare un valore tra i postmeta e utilizzarlo all’interno del pannello del blocco che stavo creando.
L’attributo era quindi così:

overallRating: {
type: ‘number’,
source: ‘meta’,
meta: ‘yasr_overall_rating’
}

Alla prima apertura di Gutenberg viene correttamente pescato, e a un determinata azione dell’utente, (quando inserisce un nuovo voto) il valore nel database viene aggiornato.
Quello che succedeva però era che, nonostante il valore nel database fosse correttamente aggiornato, quando il post veniva salvato o aggiornato, il valore per qualche oscuro motivo veniva ritornato come undefined . Questo succede solo quando il post viene aggiornato o salvato: ricaricando la pagina veniva visualizzato quello corretto.

Il mio workaround, che poi ho scoperto è stata anche la soluzione suggerita nell’issue su GitHub, è stata quella di lavorare con due attributi diversi

//this is from post meta
overallRatingMeta: {
type: ‘number’,
source: ‘meta’,
meta: ‘yasr_overall_rating’
},
//this is from gutenberg comments
overallRatingAttribute: {
type: ‘number’,
default: 0
},

Il secondo attributo è uno di quelli di default di Gutenberg, che salva i dati come commenti del blocco, e che funziona senza noie.
Se il post è nuovo, o se non ha lo shortcode salvato, overallRatingAttribute sarà sempre 0. In questo caso, assegno a overallRatingAttribute il valore di overallRatingMeta.
Se, invece, nel post è gia presente lo shortcode , overallRatingMeta non verrà mai utilizzato.

Spero che questa post possa aiutare a risparmiare tempo a chi come me deve leggere o manipolare dei post meta all’interno di Gutenberg.

/0 Commenti/da

Wp Mail Smtp – Un plugin con oltre 1 milione di installazioni attive che dovresti smettere di usare SUBITO

, ,

Ci sono diversi motivi per cui si sceglie di usare un servizio di SMTP esterno per l’invio delle email piuttosto che usare le funzioni standard di WordPress (o php) : in primis la maggiore affidabilità, ma anche la possibilità di avere delle statistiche non è affatto male (per non parlare dell’invio di mailing list con servizi esterni).

Cercando un plugin per svolgere il compito, ci si imbatte sicuramente in Wp Mail Smtp: conta oltre 1 milione di installazioni attive ed è consigliato da articoli/tutorial come quelli di SiteGround, Dreamhost e tantissimi altri.

Con questi numeri, uno si fida e lo installa più o meno ad occhi chiusi.

Un errore assai grave, purtroppo, ora vi spiego perchè punto per punto.

Questa è la pagina delle impostazioni del plugin, la parte in cui si inseriscono i parametri per il login (come parametri ho usato smtp.provideracaso.it come host, come indirizzo email [email protected] e come password passwordacaso)

Impostazioni parametri login per wp mail smtp

Qui, subito notiamo che qualcosa non quadra:

The password is stored in plain text. We highly recommend you setup your password in your WordPress configuration file for improved security; to do this add the lines below to your wp-config.php file.
define( ‘WPMS_ON’, true );
define( ‘WPMS_SMTP_PASS’, ‘your_password’ );

Un messaggio ci avverte che la password è salvata nel database in chiaro, ammenoché non definiamo quelle due costanti nel file wp-config.php.

E già da qui mi viene da chiedere perchè cavolo si lascia la possibilità di salvare la password in chiaro allora, visto che c’è un metodo più sicuro.
Che più sicuro non è, come vedremo più avanti.

Diciamo che io sono uno scemo, non me ne frega niente di quel messaggio e la password la salvo comunque in chiaro.
Nella tabella _options, se cerco %smtp%, ecco che compare tra le altre una riga che si chiama wp_mail_smtp, con la nostra bella password in chiaro, come ci avevano avvertito:

Wp mail smt parametri nel db

È TUTTO VERO!
Cancelliamo subito quella riga dal db e inseriamo quelle due costanti che ci aveva detto prima! (che è comunque una soluzione orrenda)

Ecco come appaiono ora le impostazioni:

Impostazioni parametri login per wp mail smtp con le define

Notiamo subito come il campo password è preinserito e non modificabile; oltre questo il warning è sparito.

Siamo a posto no?
Ho fatto il bravo, ho seguito le istruzioni, sono al sicuro giusto?
Diciamo che ignoro che salvare la password in una costante invece che nel db non è una soluzione ma solo una grandissima minchiata, andiamo a vedere come cambia ora il nostro db:

Wp mail smt parametri nel db anche dopo la define

Holy Shit!
Ma solo a me sembra uguale a prima?

Ora, leggendo la loro doc, c’è questo passaggio

Unlike other Gmail SMTP plugins, our Gmail SMTP option uses OAuth to authenticate your Google account, keeping your login information 100% secure.
Read our Gmail documentation for more details.

In poche parole se si usa Gmail effettuano il login con OAuth.

Ora, qualora anche volessi utilizzare Gmail come host SMTP, alla luce di tutto questo, non lo farei mai e poi mai, la fiducia verso questo plugin e i suoi sviluppatori è crollata a 0.

Vi consiglio, invece, Post SMTP Mailer. Un plugin pensato in primis alla sicurezza, e oltre a questo ha anche funzioni in più (un giorno se mi va, forse, farò un tutorial).

P.s. Una volta disinstallato il plugin, i dati rimangono li.
Dovrete cancellarli a mano.

/3 Commenti/da