Enhancing user experience in your WordPress store is crucial for standing out and improving customer interaction and reviews area is one of the most used by customers who want to figure out if a certain product fits their needs or not, based on the experience of other users.
By default, WooCommerce products reviews use the avatar associated with the logged-in user, but it can be more beneficial to show the avatar based on the email provided in the comment. Here’s how you can achieve this.
What is Gravatar?
Gravatar (Globally Recognized Avatar) is a service that provides globally unique avatars based on users’ email addresses. When users comment on your site and provide their email, the corresponding Gravatar is displayed, adding a personal touch and increasing the authenticity of the reviews.
WordPress natively integrates Gravatar to grab comment/reviews profile image, as well as in other areas (such as back-end user pages).
Solution implementation
I struggle a little bit to find the right filter to use for my purpose; eventually I bumped into get_avatar.
This filter allows us to intercept and modify the displayed avatar based on the email entered in the comment field rather than the logged-in user e-email. Here’s the code to implement this solution:
<?php
function custom_get_avatar_for_product_review( $avatar, $id_or_email, $args ) {
// Check if the object is a comment
if ( is_object( $id_or_email ) && isset( $id_or_email->comment_ID ) ) {
$comment = $id_or_email;
// Check if the comment is associated with a WooCommerce product
if ( get_post_type( $comment->comment_post_ID ) == 'product' ) {
// Get the commenter's email from the comment email field
$commenter_email = get_comment_author_email( $comment->comment_ID );
// Generate the Gravatar for the commenter's email
$avatar = get_avatar( $commenter_email, $args['size'], $args['default'], $args['alt'], $args );
}
}
return $avatar;
}
add_filter( 'get_avatar', 'custom_get_avatar_for_product_review', 10, 3 );
NOTE: As you can notice we limited this functionality to product post_type, you can change according to the needs you want to fullfill.
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:
