Autore: UMNW

Chi lavora con Oxygen Builder e WooCommerce lo sa: ogni tanto qualche aggiornamento importante di WooCommerce manda in tilt cose che prima funzionavano senza battere ciglio. Siamo compagni di viaggio su questo sentiero lastricato di frustrazione, specie se gestisci decine di siti e devi trovare una soluzione veloce … o scappare su un’isola dove non ci sia internet e copertura telefonica.

È successo di recente con la Product List: improvvisamente le gallerie e gli script legati ai prodotti singoli hanno smesso di funzionare. E con ciò intendo dire che non si vedono più, di punto in bianco e senza motivazioni visibili, che permettessero un minimo di retroingegneria.

Risultato? Un front-end spezzato, con utenti che non vedono più zoom, lightbox o variazioni, clienti felicissimi di ciò e ore spese in ricerca della soluzione.

Dopo un poco di tempo che ero andato avanti forzando l’opacità delle immagini in product list, mi sono reso conto che il problema era lato Javascript, non perché avessi degli utili errori che mi mettessero sulla via della risoluzione, ma perché anche i tab, il lightbox e quant’altro non funzionavano nemmeno per il … caso.

Il CSS era questo:

.woocommerce-product-gallery {
    opacity: 1 !important;
}

Funzionicchiava, certo i prodotti si vedevano, ma niente lightbox, niente tab prodotto avrebbero certamente degradato l’esperienza utente.

Allora, ci siamo

Gira che gira, tienimi che ti tengo, abbiamo trovato la discussione utile in questo gruppo Facebook: Oxygen Builder Community – Fix post, grazie Henio Henio <3.

A quanto si è capito che WooCommerce non carica più automaticamente lo script wc-single-product nella Product List, o forse sarebbe meglio dire, che Woocommerce ha cambiato le carte in tavola e ha sfondato il modo in cui gli script venissero caricati per il prodotto singolo in Oxygen Builder.

Morale della favola: c’era bisogno di forzarlo.

La soluzione rapida: code block PHP

Se vuoi un fix immediato, puoi aprire il tuo template con Oxygen e inserire un Code Block PHP con dentro:

<?php
  wp_enqueue_script('wc-single-product');
?>

Dove metterlo? Nel template del singolo prodotto ovviamente.

Questo dice a WordPress: “Ehi, quando sei in una pagina prodotto, carica anche lo script che serve a far girare la galleria, lo zoom e tutte le funzioni fighe del single product”.

Ha funzionato benissimo.

La soluzione elegante: un MU-Plugin

NOTA: questa a me non ha funzionato e sono virato sul code block.

Sei un maniaco come me e non vuoi insozzare il sorgente?

Se vuoi una soluzione permanente e meno “pezza a colori”, puoi creare un mu-plugin. Basta aprire la cartella wp-content/mu-plugins/ (se non esiste, creala) e inserire un file chiamato fix-oxygen-wc-single-product.php con questo codice:

<?php
/**
 * Plugin Name: Fix Oxygen WooCommerce Single Product Scripts
 * Description: Forza il caricamento dello script wc-single-product nelle pagine prodotto WooCommerce.
 * Author: Un Moscerino nel Web
 * Version: 1.0
 */

add_action('wp_enqueue_scripts', function() {
    if (is_product()) {
        wp_enqueue_script('wc-single-product');
    }
}, 20);

In questo modo non dipendi da Oxygen né da aggiornamenti strani: lo script viene caricato solo quando serve, senza sporcare i tuoi template.

Ripeto, questo modus dovrebbe essere il migliore in teoria, ma a me non ha funzionato.

Tirando le cu… somme

Il bello di lavorare con WordPress è che riesci a tirare su un sito in poco tempo e ci sono migliaia e migliaia di soluzioni già pronte. Il brutto ? Lavorare con WordPress + Oxygen + WooCommerce è che gli aggiornamenti non perdonano. A volte tocca rimboccarsi le maniche e aggiungere due righe di codice per rimettere tutto in sesto.
A volte bisogna fare dei rollback, ripristini, rollback di vecchie versioni eccetera.

Sono questi i momenti in cui commisero me stesso per non aver creato la mia soluzione con Laravel o chissà cosa per essere indipendente dal mondo …

Se usi Laravel per progetti un po’ più complessi del classico “todo list”, prima o poi ti scontri con il sistema di traduzioni. Funziona bene, è flessibile, ma ha le sue particolarità — e se non sai dove mettere le mani rischi di impazzire davanti a un “These credentials do not match our records” che continua a spuntare in inglese anche se hai già scritto la tua bella frase in italiano.

Vediamo come funziona davvero, senza fumo negli occhi.

Due strade: JSON e file PHP

Laravel supporta due approcci per le traduzioni:

1. File JSON (resources/lang/it.json)

• È un file unico per lingua.
• La chiave è la stringa letterale in inglese, il valore è la traduzione.
• Esempio: { "Log in": "Accedi", "Remember me": "Ricordami" }
• Usato soprattutto dalle viste generate da Breeze, Jetstream e compagnia bella, che scrivono direttamente __('Log in') o __('Remember me').

È semplice e veloce: traduci stringa per stringa senza namespace.

2. File PHP (resources/lang/it/auth.php, validation.php, ecc.)

• Qui le chiavi sono logiche, non testuali.
• Esempio per l’autenticazione: <?php return [ 'failed' => 'Le credenziali non corrispondono ai nostri dati.', 'password' => 'La password fornita non è corretta.', ];
• In questo caso il codice chiama __('auth.failed') invece della stringa intera.

È il sistema usato da Laravel “interno”: errori di validazione, messaggi di login, reset password, ecc.

Locale e fallback

Le traduzioni vengono lette in base al locale impostato.

• In config/app.php: 'locale' => 'it', 'fallback_locale' => 'en',
• Oppure nel .env: APP_LOCALE=it

Attenzione: se hai fatto php artisan config:cache, il .env non viene più letto direttamente, quindi ti conviene hardcodare locale in config/app.php o ripulire la cache.

La cache, maledetta cache

Se traduzioni e locale non cambiano, il 90% delle volte è colpa della cache.
Ripulire è la prima cosa da fare:

php artisan optimize:clear
php artisan config:clear
php artisan cache:clear
php artisan view:clear

Dopo, ricarica la pagina con un hard refresh del browser.
Se vuoi essere ancora più sicuro, testa in Tinker:

php artisan tinker
>>> app()->getLocale()
"it"
>>> __('auth.failed')
"Le credenziali non corrispondono ai nostri dati."

Se qui funziona, funziona anche nel browser.

JSON o PHP? Quando usare cosa

• JSON → per le label e i testi “visibili” nelle view (Log in, Forgot your password?).
• PHP → per i messaggi di sistema (auth.failed, errori di validazione, reset password).

Puoi usarli anche insieme senza problemi: Laravel li fonde.

Personalizzare i messaggi di sistema

Vuoi cambiare il testo dell’errore di login? Vai in resources/lang/it/auth.php:

'failed' => 'Utente o password non validi.',

Vuoi tradurre la frase lunga del “Forgot your password?”?
Mettila nel JSON:

{
  "Forgot your password? No problem. Just let us know your email address and we will email you a password reset link that will allow you to choose a new one.": "Hai dimenticato la password? Nessun problema: inserisci la tua email e ti invieremo un link per reimpostarla."
}

Debugging: checklist rapida

1. Locale impostato in config/app.php
2. Cache ripulita (optimize:clear, config:clear, ecc.)
3. Stringa giusta nel file giusto (auth.failed nei PHP, testi letterali nel JSON)
4. Test con Tinker: __('auth.failed') deve restituire italiano

Conclusione

Il sistema di traduzione di Laravel è flessibile, ma non sempre intuitivo se non sai la differenza tra file JSON e file PHP namespaced.
La regola è semplice: UI nel JSON, messaggi di sistema nei PHP. E quando non funziona… la colpa è quasi sempre della cache.