Woocommerce prodotti variabili divenuti improvvisamente semplici

Sto scrivendo questo post per il bene dell’umanità, perché nemmeno il più empio dei bipedi umanoidi del globo terraqueo merita di passare per quello che sono passato io.

Vi dico subito che le soluzioni semplici sono le più efficaci e che se vi trovate nella situazione in cui, di punto in bianco, tutti i prodotti variabili del vostro sito sono divenuti semplici sia da backend che da frontend, allora questo articolo può aiutarvi.
Più precisamente se il vostro prodotto fintamente semplice, quando siete in modifica e cambiate il tipo in variabile, carica delle pre-esistenti variazioni, e salvando bonificate la situazione, allora direi che siete proprio nel posto giusto.

Non sto qui a spiegarvi tutti gli approcci che ho adottato e che sono miseramente falliti, andiamo direttamente al punto spiegando in primis qual era la situazione.

Cosa era successo?

Lo ignoro, ho ereditato questa grana da terzi e senza la possibilità di tornare in uno stato precedente, senza backup e senza informazione.
Ho letto la qualunque sull’internet, per taluni si trattava di un conflitto ( interiore? 😀 ) ma nel mio caso:

  • disattivando tutti i plugin
  • passando al tema ad un tema di default (Twenty twenty three)
  • togliendo la cache dall’equazione
  • assicurandomi che la CDN non rompesse le scatole
  • riavviando il pc (ovviamente questo non l’ho fatto davvero!)

e facendo tutte le altre prove che suggerisce l’intuizione o l’intelligenza artificiale non ho cavato un ragno dal buco. Zero carbonella, come dicono in capitale, nisba, nada … crio.

Con un elenco di più di 500 prodotti affetti dal problema capite bene che andare lì manualmente a editare prodotto per prodotto sarebbe stato un guaio passato.

Pertanto sono andato alla ricerca di fix programmatici, ho scritto plugin, soluzioni che eseguivano operazioni in batch e altre cose anche molto sofisticate, ma sono solo riuscito a sfondare l’archivio prodotti. Tristezza per favore vai via.

Alla fine mi sono messo con calma zen e ho chiesto a chatgpt di farmi uno script che mi consentisse di ottenere un report in json descrittivo del prodotto.

Tale fix sarebbe stato lanciato prima e dopo la modifica manuale del prodotto fintamente semplice in variabile (cosa che come vi ho già detto, aggiustava le cose).

Ho preso il codice php che mi ha suggerito la lattina (povero ChatGPT) e ho creato un file report.php che ho messo nella root di wordpress per poterlo richiamare da browser, eccolo:

<?php
// Assicurati che questo file venga eseguito in un contesto WordPress
require_once('./wp-load.php');

if (!isset($_GET['product_id']) || !is_numeric($_GET['product_id'])) {
header('Content-Type: application/json');
echo json_encode(['error' => 'Missing or invalid product_id parameter.']);
exit;
}

$product_id = intval($_GET['product_id']);
$data = [];

// Recupera dati da wp_posts
$product_post = get_post($product_id);
if ($product_post) {
$data['post'] = [
'ID' => $product_post->ID,
'post_title' => $product_post->post_title,
'post_type' => $product_post->post_type,
'post_status' => $product_post->post_status,
];
} else {
$data['post'] = 'Product not found in wp_posts.';
}

// Recupera dati da wp_postmeta
$postmeta = get_post_meta($product_id);
$data['postmeta'] = $postmeta ?: 'No metadata found for this product.';

// Recupera termini collegati nella tassonomia product_type
$terms = wp_get_object_terms($product_id, 'product_type');
if (!is_wp_error($terms)) {
$data['taxonomy'] = array_map(function ($term) {
return [
'term_id' => $term->term_id,
'name' => $term->name,
'taxonomy' => $term->taxonomy,
];
}, $terms);
} else {
$data['taxonomy'] = 'Error fetching terms: ' . $terms->get_error_message();
}

// Imposta l'intestazione per il JSON
header('Content-Type: application/json');

// Ritorna i dati in formato JSON
echo json_encode($data, JSON_PRETTY_PRINT);

Richiamando la url miosito.it/report.php?product_id=123, ho ottenuto il report relativo al prodotto, quindi ho salvato il prodotto da interfaccia cambiando manualmente il type da simple a variable e ho rigenerato il report.

Dal confronto dei due file è emerso che si era sballata la tassonomia che gestisce il tipo prodotto. Se siete confusi è giusto che sia così, perché sappiate che c’è una tassonomia che gestisce il tipo prodotto …

Tale tassonomia ha vari termini (uno per tipo di prodotto) e ciascuno ha il proprio identificativo (term_id). Il mio termine “variabile” aveva term_id = 842.

Pertanto mi sono detto, perché non fare una bamonda query che prenda tutti i prodotti fintamente semplici e ci metta su, questa cavolo di associazione con il termine giusto?

I prodotti fintamente semplici (e intrinsecamente variabili) erano reperibili verificando che avessero effettivamente almeno un post_parent che gli puntasse (ovvero le variazioni).

Ha funzionato bene, ecco la query:

-- Associare i prodotti fintamente variabili al termine "variable" (term_id 842)
INSERT INTO wpon_term_relationships (object_id, term_taxonomy_id)
SELECT
p.ID AS product_id,
842 AS term_taxonomy_id
FROM
wpon_posts AS p
LEFT JOIN
wpon_posts AS v ON v.post_parent = p.ID AND v.post_type = 'product_variation'
LEFT JOIN
wpon_term_relationships AS tr ON p.ID = tr.object_id
LEFT JOIN
wpon_term_taxonomy AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
LEFT JOIN
wpon_terms AS t ON tt.term_id = t.term_id
WHERE
p.post_type = 'product' -- È un prodotto
AND v.ID IS NOT NULL -- Ha variazioni associate
AND (t.term_id IS NULL OR t.term_id != 842) -- Non è già associato a "variable"
GROUP BY
p.ID
ON DUPLICATE KEY UPDATE term_taxonomy_id = VALUES(term_taxonomy_id);

Ovviamente 842 è il mio id, trova il tuo nel database e modifica lo script prima di lanciarlo.

ATTENZIONE: non essere dissennato EFFETTUA UN BACKUP prima di distruggere tutto.

In fine

Questo problema non voglio doverlo risolvere mai più! 🙂

È stato uno stress non indifferente venire a capo dei perché e dei percome, spero torni utile a voi altri.

Dump database Mysql/Maria DB in file separati

Come eseguire un export su file di tutti i database su un server Mysql da riga di comando.

Avevamo già parlato di come effettuare il backup di tutti i database mysql per mezzo di uno script bash, ma di recente un mio collega mi ha segnalato una soluzione, che secondo me è molto più elegante.

Si tratta di un singolo comando da eseguire sulla linea di comando con i pipe (questo è il pipe “|”).

Ecco il comando:

mysql -N -e 'show databases' | while read dbname; do mysqldump --complete-insert --routines --triggers --single-transaction "$dbname" > "$dbname".sql; [[ $? -eq 0 ]] && gzip "$dbname".sql; done 

Vediamo i comandi nel dettaglio; per farlo scriviamo sulla cli quanto segue:

mysql --help

-N, –skip-column-names
Don’t write column names in results.

L’opzione -N non fornisce in output il nome della colonna, nel nostro caso la lista dei database sarà quindi priva di intestazione ed utilizzabile nel while successivo al primo pipe.

-e, –execute=name Execute command and quit. (Disables –force and history
file.)

L’opzione -e, consente di eseguire il comando tra apici, ovvero “‘show databases'”.

La parte che segue il pipe (“|”) prende come input l’output di quello che lo precede, consentendo di effettuare un ciclo while sul nome di ogni database e di fare un dump con il comando mysqldump.

Forse si può fare meglio, ma il kata-programming non va abusato e chi si accontenta gode!

Detto questo se vi mettete a smanettare con quello script, postate tutto nei commenti.

Backup di tutti i database mysql

Talvolta capita di dover cambiare pc o semplicemente cambiare versione del proprio virtual web server locale preferito. Sia esso Xamp, Mamp o Wamp il concetto è sempre lo stesso. Dobbiamo trasportare i database da un posto ad un altro.

Problema

Ho più database sul mio mysql (locale o remoto) di cui devo ottenere un backup. Il comando che segue ci consente di effettuare questa operazione da linea di comando è il seguente:

mysqldump -u NOME_UTENTE -p NOME_DATABASE > /percorso/dove/salvare/ildatabase.sql

Come si può facilmente notare in questo modo sarà creato un dump del singolo database mysql in un file .sql.

Tuttavia talvolta è necessario esportare tutti i database presenti su mysql. A tale scopo si rende indispensabile creare uno script.

Soluzione

È possibile creare uno script che con pochi comandi adempia al compito desiderato: esportare tutti i database mysql con uno script.

Lo script verrà inserito in un file con estensione .sh, che è possibile eseguire sia su Windows, sia ovviamente su Linux e Mac.

Su Windows è possibile farlo con la bash di git o cygwin, in linux eseguendo da riga di comando

sh nomescript.sh

oppure

bash nomescript.sh

a seconda dell’interprete che si desidera utilizzare.

Ma veniamo alla soluzione riportata direttamente dal blog di Daniel Dvorkin:

#!/bin/bash
 
USER="DATABASE_USERNAME"
PASSWORD="DATABASE_PASSWORD"
OUTPUT="/path/to/backup/folder/"
 
rm "$OUTPUT/*gz" > /dev/null 2>&1
 
databases=`mysql --user=$USER --password=$PASSWORD -e "SHOW DATABASES;" | tr -d "| " | grep -v Database`
 
for db in $databases; do
    if [[ "$db" != "information_schema" ]] && [[ "$db" != _* ]] ; then
        echo "Dumping database: $db"
        mysqldump --force --opt --user=$USER --password=$PASSWORD --databases $db > $OUTPUT/`date +%Y%m%d`.$db.sql
        gzip $OUTPUT/`date +%Y%m%d`.$db.sql
    fi
done

Una volta inserito in un file di testo, con estensione “sh”, lanciando questo script consentirà di creare un file tar.gz contentente un file .sql per ciascun database presente nel proprio mysql.

È possibile ottenere file zippati con un altro sistema o non compressi affatto semplicemente intervenendo sulla riga dello script che comincia con “gzip” (cancellandola ad esempio si otterrà un file .sql non compresso).

Si noti che la cartella di destinazione deve esistere prima di lanciare lo script, che altrimenti potrebbe fallire miseramente.

Ho testato la soluzione e devo dire che mi è stata molto utile in quanto pratica e veloce.

Ora devo cercare/scrivere uno script per caricare tutti i database siffatti da una cartella ai database veri e propri, ma questo sarà un’altro post.