Il debug è uno stress? Con questi piccoli accorgimenti non vi peserà più tanto.
Un mio collega di qualche tempo fa, l’ottimo G. Bove, si portava sempre dietro la sua cassetta degli attrezzi chiamata GBTools, una libreria di funzioni e snippet PHP in cui compariva anche la funzione dumpa (letto dampa), che effettuava un semplice dump su file di quello che gli passavi (variabili, oggetti, array, stringhe eccetera).
In suo omaggio, utilizzerò lo stesso nome per la mia funzione di log su file, ecco il codice che potrete scrivere dove vi pare, ma che vi consiglio di mettere in un file sempre richiamato nel vostro progetto.
Questa funzione scriverà quello che gli verrà passato sul file my.log (nella directory in cui viene dichiarata la funzione). Ad onor del vero non ricordo come fosse strutturata quella da cui ho tratto ispirazione, ma alla fine fa il suo sporco lavoro.
Per poter leggere il file my.log, potete ovviamente aprirlo con un qualunque editor, o fare una cosa più figa e, soprattutto, più efficiente.
Se siete su ambiente Linux e (ancora) non conoscete il comando tail, provate a lanciare da bash quanto segue:
tail -f my.log
Lasciate la console aperta e affiancatela al vostro editor o browser per vedere i risultati del vostro debug in tempo reale.
Ho trovato, ma non testato, anche un modo per ottenere il comando tail su ambiente windows, fatemi sapere nei commenti se funziona.
Minimo sforzo massima resa, in questo post spiego come ho fatto a risolvere il problema che un mio cliente aveva generato per errore. Oltre alla soluzione troverete anche l’iter che mi ci ha portato.
A seguito di un’importazione sbagliata, un mio cliente aveva riempito il suo e-commerce (woocommerce) di 2000 prodotti vuoti! Fortunatamente si trattava di un ambiente di pre-produzione e quindi non ha avuto alcun impatto sull’esperienza utente.
Tuttavia si era reso necessario un intervento massivo su tutti i prodotti, in quanto andavano eliminati del tutto dal sito internet.
Il mio cervello ha pensato subito a scrivere un poco di codice per creare uno script da lanciare in batch attraverso di un plugin ad hoc, che avrebbe dovuto esporre una pagina con un pulsante di distruzione di massa, quindi esporre un avviso per chiedere all’utente se fosse sicuro di quello che stava facendo … ma sono troppo pigro, per cui, il secondo pensiero è stato gugolare un poco (anche se in realtà uso perlopiù duckduckgo, ve lo consiglierò prima o poi assieme ad altri tool per la vostra privacy).
Dalla ricerca che ho usato wordpress how to delete all products è venuto fuori (ovviamente) la qualunque … focalizzerò l’attenzione su 2 delle soluzioni che ho trovato.
1. Aumento numero prodotti visualizzati
Parte superiore della pagina prodotti di wordpress/woocommerce
Alcuni consigliano di visualizzare più prodotti sulla stessa pagina e cancellarli massivamente
Ma questa soluzione, mostrando un numero considerevole di prodotti (anche 300), è veramente sconsigliata per tanti motivi:
è maledettamente lenta;
prevede dei tempi morti perfino lato client (javascript ci mette un po’ a spuntare tutte le checkbox!);
anche se il processo di cancellazione massiva viene gestito in batch, ottimizzando l’uso della memoria RAM, vi ritroverete comunque a consumare molte risorse e ad aspettare molto tempo prima che la nuova pagina venga ricaricata e possiate lanciare un altro cancella tutti.
Questa soluzione per me è quindi SCONSIGLIATA. Passiamo alla prossima
2. Query diretta al database che rimuove tutto
Non male come idea. Una bella query, fatta bene che va a togliere non solo i prodotti, ma tutte le sue relazioni con le altre risorse BASE di wordpress.
Quel “BASE” non è maiuscolo per caso. Quello che intendo impropriamente dire con risorse BASE, significa che se per qualche motivo il vostro prodotto è collegato a qualche altra risorsa introdotta da un plugin o da software di terze parti, rischiate seriamente di perdervi pezzi per strada.
Uno screenshot della soluzione così come riportata su Store App org.
Il sito storeapps.org, propone una soluzione basata su questa query:
DELETE relations.*, taxes.*, terms.*
FROM wp_term_relationships AS relations
INNER JOIN wp_term_taxonomy AS taxes
ON relations.term_taxonomy_id=taxes.term_taxonomy_id
INNER JOIN wp_terms AS terms
ON taxes.term_id=terms.term_id
WHERE object_id IN (SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
DELETE FROM wp_postmeta WHERE post_id IN (SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
DELETE FROM wp_posts WHERE post_type IN ('product','product_variation');
Ma ad ogni modo, lo stesso autore dopo questa query dice:
However, this is not the best way to bulk delete products
Anche se loro sconsigliano l’approccio query based, perché vogliono vendervi un plugin che fa cose, quella che dicono è una grande verità.
Troppo rischioso lanciare query nel database senza alcuna pietà. Potresti ritrovarvi con più problemi di quando avete iniziato.
Se scegliete questo approccio che io SCONSIGLIO, abbiate almeno il buon cuore di effettuare una copia di backup del database (ho scritto anche io un poco a riguardo).
3. WP CLI
La WP CLI è un software portabile scritto in PHP che vi consentirà di lanciare dei comandi sulla console per ottenere quello che volete.
Non sai di che parlo? Fidati di me, usa il metodo 1.
wp post list --field=ID --post_type=product --posts_per_page=2000 | xargs wp post delete --force
Il comando che ho lanciato sul terminale dell’hosting in questione. Come è possibile vedere ho usato direttamente il file .phar.
Se avete il sito su hosting che non ha accesso alla console sappiate che potete usare lo stesso la cli, ma facendo un accrocchio che spero di avere modo di illustrarvi in qualche altro post in futuro.
Conclusioni
Se siete utenti smaliziati, dovete avere a che fare con operazioni ripetitive, containers, orchestratori (tipo kuberneetes), allora vi consiglio di studiare l’uso della CLI (proposta come migliore soluzione, la numero 3).
Se non siete utenti esperti state lontano come la peste dalle query (soluzione 2) e lanciatevi sulla soluzione 1, specie se la cancellazione massiva è da fare una tantum.
Sometimes can happen that the email sent through woocommerce have incorrect data. Where are placeholders data stored, for instance {site_name}, {site_address}, {order_number}, used in Dokan email templates? And, how to modifify {site_name} placeholder?
In my case {site_name} placeholder value was referring to an old site name, still present after a migration, due to this I bumped into the necessity of change placeholder value.
A screenshot WordPress wp-config.php file, where the database table prefix is defined.
To get the job done I was obliged to do the modification at mariadb/mysql database level. More specifically “{site_name}” was defined in “PREFIX_options” table, where PREFIX is your database table prefix defined in wp-config.php file at installation time.
The option to find out in my case was “woocommerce_email_from_name“, that represents {site_name} placeholder in Dokan email templates.
I came across it through phpmyadmin search functionality, searching for the name, the wrong one I want to replace, appearing on the email sent to users.
An example of how Dokan is translating placeholder into bare text is the method trigger, defined in plugins/dokan-pro/modules/rma/includes/emails/class-dokan-rma-send-coupin-email.php php file:
