Nel refactoring di un ecommerce, ci sono due tipi di problemi:

1. quelli previsti
2. quelli che scopri mesi dopo… quando è troppo tardi

Tutti conosciamo la teoria delle migrazioni perfette: ambienti di staging, backup ridondanti, controlli QA rigorosi. E poi c’è la realtà.

Recentemente mi sono trovato in uno scenario da incubo durante il refactoring di un e-commerce (migrazione da WooCommerce a Next.js + LunarPHP).

Durante la migrazione, un freelance si occupa dell’importazione dei dati: prodotti, varianti, prezzi, categorie, media. Alla consegna facciamo controlli preliminari: tutto sembra ok, il freelance si congeda, passano settimane, poi mesi, si va online.

Dopo il go-live, ci accorgiamo che qualcosa non torna. Un gruppo di prodotti, nell’ordine delle migliaia, risulta senza immagini.

E nel commercio elettronico, un prodotto senza immagine è praticamente un prodotto invisibile:

• conversione bassa
• UX compromessa
• fiducia ridotta
• catalogo “rotto”

Il disastro operativo: niente backup e freelance irreperibile

A quel punto iniziano le domande: recuperiamo dal vecchio hosting? Chiediamo al freelance di rigenerare la migrazione?

Peccato che: il contratto con il vecchio hosting era stato disattivato e quindi sorgenti e gli upload non erano più accessibili, il freelance era impegnato su altro e quindi… sparito.

Che si fa?

La risposta classica sarebbe:

• ripetere shooting fotografico o recuperare manualmente immagini, magari chiedendole al fornitore
• ricostruire tutto a mano

Ma su migliaia di SKU non è una soluzione. Serviva qualcosa di diverso. Una soluzione creativa disponibile in poche ore, al massimo giorni, non settimane.

Automatizzare l’impossibile usando PHP, Google Custom Search e Computer Vision.

Ma c’è un problema: cercare su Google non è semplice come sembra. Non è sempre tutto oro quel che luccica nelle prime posizioni.

Fase 1: La strategia di “scraping” (Search Fallbacks)

Se cerchi PRODOTTO-123 Bracciale Argento potresti non trovare nulla. Magari Google ha indicizzato il prodotto, ma senza il codice SKU nel titolo. Oppure ha lo SKU, ma il nome è leggermente diverso.

Per questo, nel mio GoogleSearchService, non mi sono limitato a una singola query “secca”. Ho implementato una strategia a 4 livelli di profondità (Fallback Strategy) per “scavare” nella SERP finché non emerge qualcosa di utile.

Ecco come ragiona l’algoritmo quando cerca un’immagine:

1. Il Tentativo Ottimista (Query Completa) Cerca la stringa esatta: SKU + Nome Prodotto. È la situazione ideale, ma spesso fallisce se il vecchio sito non aveva un buon SEO o se lo SKU è interno.
2. La Pulizia (Sanitization Fallback) Se il primo tentativo fallisce, l’algoritmo riprova rimuovendo la “sporcizia”. Via punteggiatura, trattini inutili e spazi doppi. Spesso Google si confonde con simboli come _ o / in eccesso.
3. L’Approccio Semantico (Solo Nome Prodotto) Qui si rischia di più, ma si ottengono più risultati. Se lo SKU “sporca” la ricerca, lo rimuoviamo brutalmente dalla stringa e cerchiamo solo il nome (es. “Bracciale Pandora Argento”). Rischio: Trovare prodotti simili ma non identici. Soluzione: Qui è fondamentale la validazione successiva con l’AI.
4. L’Approccio Tecnico (Solo SKU) Ultima spiaggia. Cerchiamo solo il codice identificativo. Funziona benissimo per ricambi o elettronica, dove lo SKU è univoco nel mondo, ma malissimo per prodotti generici.

Solo combinando questi quattro approcci siamo riusciti a passare dal “Nessun risultato trovato” a una lista di candidati plausibili per il 90% dei prodotti mancanti.

Fase 2: Il Cervello (Vision + DeepL)

Trovare l’immagine è solo metà dell’opera. Scaricare l’immagine sbagliata è peggio che non averne nessuna. Come distinguere un “Bracciale Pandora” dal “Vaso di Pandora” o dal pianeta di Avatar?

Ho creato un GoogleVisionService che funge da giudice imparziale:

1. Analisi Visiva: Google Cloud Vision analizza l’immagine candidata e ci dice cosa vede (es. ['Jewelry', 'Silver', 'Bracelet']).
2. Ponte Linguistico: Usiamo DeepL per tradurre le nostre keyword italiane (es. “Bracciale”) in inglese, la lingua nativa delle label di Vision.
3. Relevance Score: Incrociamo i dati. Se le etichette dell’immagine matchano con le keyword tradotte del prodotto, il punteggio sale. Se il punteggio supera il 0.7 (o il 70% di confidenza), l’immagine è approvata.

L’idea è stata usare Google Vision AI come “semantic gatekeeper”, quindi non come riconoscitore generico, ma come filtro semantico automatico:

“Questa immagine appartiene davvero al contesto del prodotto?”

Il ponte linguistico è il vero “hack”

Poiché Google Vision restituisce etichette in inglese, abbiamo usato DeepL (anche questo strumento è AI based) come traduttore in tempo reale degli attributi del prodotto. Questo ci ha permesso di confrontare “Silver” (etichetta AI) con “Argento” (attributo colore presente a DB), garantendo che il match semantico non andasse perso nella traduzione. Un saluto a Silver, il creatore di Lupo Aberto, che grazie a questo hack non è finito in mezzo alle foto dei prodotti.

Non solo pertinenza: la sicurezza del Brand

Quando automatizzi il download di immagini da Google, il rischio “contenuti inappropriati” è dietro l’angolo. Nel codice ho integrato un filtro basato sulla SafeSearch detection di Vision AI. Se l’algoritmo rileva una probabilità elevata di contenuti adult, violence o racy, l’immagine viene scartata a prescindere dal punteggio di pertinenza. Automatizzare sì, ma con la cintura di sicurezza allacciata.

Paragrafo per gli smanettoni: apriamo il cofano

NB: Se ti basta quanto hai letto nella Fase 2, puoi passare alla Fase 3.

Cosa restituisce davvero Vision (labelAnnotations, score e topicality)

Per ogni immagine candidata, Google Cloud Vision non “indovina il prodotto”, ma restituisce un set di etichette (label) con un livello di confidenza. Questo output è perfetto per trasformare Vision in un filtro semantico: non cerco la verità assoluta, cerco indizi coerenti col contesto.

Ecco un esempio (ridotto) di risposta per una foto che Vision interpreta come gioielleria:

{
  "responses": [
    {
      "labelAnnotations": [
        { "description": "Jewelry", "score": 0.92, "topicality": 0.92 },
        { "description": "Bracelet", "score": 0.88, "topicality": 0.88 },
        { "description": "Silver", "score": 0.84, "topicality": 0.84 },
        { "description": "Fashion accessory", "score": 0.79, "topicality": 0.79 }
      ],
      "safeSearchAnnotation": {
        "adult": "VERY_UNLIKELY",
        "violence": "VERY_UNLIKELY",
        "racy": "UNLIKELY"
      }
    }
  ]
}

Due dettagli importanti:

• description è la label (spesso in inglese);
• score e topicality sono indicatori di confidenza/pertinenza, utili per pesare le evidenze (non tutte le label “valgono” uguale).

Il ponte linguistico: dall’italiano del catalogo alle label in inglese

Il catalogo e gli attributi (colore/materiale/tipologia) erano in italiano: “bracciale”, “argento”, “ciondolo”. Vision mi rispondeva con “bracelet”, “silver”, “jewelry”. Qui entra in gioco DeepL: traduco in tempo reale (o con cache) un set di keyword “core” e confronto mele con mele.

In pratica genero un vocabolario atteso in inglese (derivato da nome prodotto + attributi) e poi uso le label Vision come evidenze.

Lo scoring: pertinenza, ambiguità semantica e “forbidden labels”

Un match string-based puro è fragile. Quello che ha funzionato è un piccolo modello di scoring:

1. prendo le label Vision più forti (es. top 8 per topicality);
2. premio le label presenti nel set “expected” (tradotto da IT → EN);
3. penalizzo label che indicano un contesto alternativo (es. “Vase”, “Mythology”, “Planet”, “Logo”);
4. scarto a prescindere se SafeSearch segnala rischi (adult/violence/racy).

Ecco uno snippet (semplificato) che rende l’idea:

$expected = ['jewelry', 'bracelet', 'silver', 'necklace', 'ring'];      // da prodotto/attributi via DeepL
$forbidden = ['vase', 'mythology', 'logo', 'software', 'planet'];      // contesti “trappola”

$labels = collect($visionLabels) // es. da labelAnnotations
  ->sortByDesc(fn($l) => $l['topicality'] ?? $l['score'])
  ->take(8)
  ->map(fn($l) => strtolower($l['description']))
  ->values();

$score = 0.0;

// Reward/Penalty semplice ma efficace
foreach ($labels as $label) {
  if (in_array($label, $expected, true)) {
    $score += 0.18;      // reward
  }
  if (in_array($label, $forbidden, true)) {
    $score -= 0.45;      // penalty forte: evita disastri tipo “Pandora = vaso”
  }
}

// Bonus se Vision è molto “sicuro” della prima label
$top = $visionLabels[0] ?? null;
if ($top && (($top['score'] ?? 0) >= 0.90)) {
  $score += 0.10;
}

// SafeSearch: cintura di sicurezza
if ($safeSearch['adult'] === 'LIKELY' || $safeSearch['adult'] === 'VERY_LIKELY') {
  return ['ok' => false, 'score' => $score, 'reason' => 'SafeSearch: adult'];
}

return [
  'ok' => $score >= 0.70,
  'score' => round($score, 2),
  'labels' => $labels->all(),
];

La cosa interessante non è tanto il valore delle costanti (che ho tarato per tentativi), ma l’idea: l’AI produce feature (label), e io costruisco sopra una policy deterministica che gestisce ambiguità semantiche. “Pandora” diventa un caso gestibile: gioiello vs mito vs altro.

Fase 3: Persistenza e audit trail, perché Spatie Media Library è stata una scelta “da produzione”

Una volta validata l’immagine, non volevo solo “attaccarla al prodotto”. Volevo anche poter rispondere, mesi dopo, a domande del tipo:

• Da dove arriva questa immagine?
• Con quale query è stata trovata?
• Quali label Vision hanno portato all’approvazione?
• Con quale score e con che decisione SafeSearch?

Qui Spatie Media Library è perfetta: offre un’API fluida per associare file ai modelli Eloquent e, soprattutto, permette di salvare metadati strutturati tramite withCustomProperties() (JSON), recuperabili e ispezionabili in modo pulito.

Nel mio caso ho salvato sia l’evidenza (Vision) sia la provenienza (Search):

$variantModel->addMedia($tempFile)
    ->withCustomProperties([
        'image_source' => 'google',
        'google_search' => [
            'query' => $query,
            'url' => $imageUrl,
            'rank' => $rank,
        ],
        'validation' => [
            'score' => $decision['score'],
            'labels' => $decision['labels'],
            'safe_search' => $safeSearch,
            'approved_at' => now()->toIso8601String(),
        ],
    ])
    ->toMediaCollection('images');

Il vantaggio pratico è enorme: se domani devo “spiegare” un’immagine o rifare una parte del processo, ho tutto in chiaro nei metadati del media item (e posso persino costruire strumenti interni per filtrare/ricontrollare le immagini già importate).

In altre parole: non ho solo ripopolato un catalogo. Ho costruito un processo ripetibile, tracciabile, e difendibile.

Il Risultato

Lanciando il comando products:fetch-variant-images, il terminale ha iniziato a raccontare una storia:

• 🔍 Processing SKU: 123-PND...
• ⚠ Query completa: 0 risultati.
• 🔄 Fallback #2 (Solo Nome): Trovate 5 immagini.
• 🔎 Validating image #1... Score: 0.15 (Rejected: Low relevance)
• 🔎 Validating image #2... Score: 0.92 (Validated!)
• ✅ Image attached.

L’algoritmo ha “ragionato” come un umano: ha provato a cercare in modo specifico, poi ha allargato il campo, e infine ha usato gli occhi (digitali) per scartare i falsi positivi.

AI come filtro operativo, non come “magia”

Questa è stata la parte più interessante del progetto: Google Vision non ha “risolto tutto”.

Ma ha permesso di costruire un sistema di cernita automatica:

• Google Search = recall (trova candidate)
• Vision AI = precision (filtra semanticamente)
• Lunar Attach = persistenza finale

Una pipeline ingegneristica completa.

Conclusioni

L’AI nel web development non serve solo a generare codice. In questo caso, l’uso combinato di Logica di Fallback (per la ricerca) e Computer Vision (per la validazione) ha trasformato un disastro annunciato in un catalogo ripopolato automaticamente.

A volte, quando perdi i sorgenti, sei costretto a scrivere codice migliore di quello che avevi prima.

Il 2025 è stato un anno in cui gran parte del lavoro non è stata “scrivere codice”, ma decidere dove metterlo, perché e con quali compromessi.

Molti dei progetti affrontati avevano una caratteristica comune:
sistemi esistenti, stratificati, con vincoli reali (budget, legacy, team distribuiti, infrastrutture già in produzione).

Di seguito una sintesi delle principali aree su cui ho lavorato.

1. Drupal avanzato e sviluppo orientato alla manutenibilità

Nel 2025 Drupal è stato il fulcro di diversi progetti complessi, spesso in contesti enterprise o multisite.

Temi ricorrenti:

• sviluppo di moduli custom Drupal 9/10/11
• override di plugin manager e access control handler
• utilizzo avanzato del modulo Group e dei suoi enabler
• comandi Drush custom per audit e standardizzazione delle configurazioni
• gestione e uniformazione di ambienti multisite (decine di installazioni)

L’obiettivo non era “far funzionare il sito”, ma:

• ridurre la divergenza tra ambienti
• rendere ripetibili le operazioni
• trasformare configurazioni implicite in regole esplicite e verificabili

2. Cloud, DevOps e automazione pragmatica

L’infrastruttura non è stata trattata come un livello separato, ma come parte integrante del design applicativo.

Attività principali:

• AWS (EC2, IAM, SSM)
• pipeline CI/CD senza accesso SSH diretto
• automazioni Bash e systemd
• strategie di disaster recovery multi-cloud
• utilizzo di Terraform / OpenTofu come strumento di controllo, non solo di provisioning
• migrazione e troubleshooting Elasticsearch → OpenSearch

Il filo conduttore: minimizzare le dipendenze implicite e rendere ogni passaggio osservabile e riproducibile.

3. Legacy, integrazioni e refactoring controllato

Una parte significativa del lavoro ha riguardato sistemi non moderni, ma ancora centrali per il business.

Esempi concreti:

• integrazione delle API REST PayPal in applicazioni ASP.NET Web Forms
• refactoring progressivo senza rompere la retrocompatibilità
• separazione delle responsabilità (helper HTTP, builder di payload, controllo del flusso)
• riduzione del coupling senza “riscritture eroiche”

Qui il tema non è stato l’upgrade tecnologico in sé, ma la riduzione del rischio.

4. Standardizzazione, accessibilità e qualità nel tempo

Nel 2025 ho lavorato spesso su aspetti che raramente fanno headline, ma che fanno la differenza nel medio periodo:

• accessibilità digitale (EAA, WCAG)
• coerenza editoriale
• qualità delle configurazioni
• governance tecnica

Standardizzare non significa irrigidire, ma:

rendere il sistema prevedibile anche per chi non lo ha progettato.

5. Tecnologia applicata a contesti non “enterprise”

Parallelamente ai progetti più strutturati, ho continuato ad applicare competenze tecniche a:

• eventi culturali e musicali
• associazioni locali
• progetti personali (musica, fotografia)

Stesso approccio, contesti diversi:

• semplicità operativa
• resilienza
• documentazione
• rispetto delle persone che useranno il sistema

Conclusione

Il 2025 non è stato un anno di hype tecnologico.
È stato un anno di scelte architetturali, di pulizia, di allineamento tra codice, infrastruttura e persone.

Meno soluzioni brillanti.
Più sistemi che continuano a funzionare anche quando chi li ha scritti non è più lì.

Ed è esattamente il tipo di lavoro che mi interessa fare.

Ovvero: un girone dantesco per chi copia composer.json invece di fare commit

Il Misfatto

Mi sono trovato davanti a questo scempio:

composer.json
composer.json.bak245p8
composer.json.bak245p8bis
composer.lock
composer-lock

E mentre contemplavo questo olocausto della ragione, ho capito: serve un girone dantesco dedicato.

Il Nono Cerchio dell’Inferno dei Programmatori

Girone dei Traditori del Version Control

«Nel mezzo del cammin della nostra codebase
mi ritrovai per una selva oscura
ché la retta via di git era smarrita»

Le Pene Eterne

I. La Bolgia dei Suffissatori Compulsivi

Qui soffrono coloro che invece di fare git commit aggiungono .bak, .old, .backup, .2, .final, .final2, .final_DEFINITIVO, .final_DEFINITIVO_stavolta_si.

Pena: Condannati a cercare per l’eternità quale sia la versione giusta tra 47 file con nomi simili, mentre un demonio alle loro spalle urla “ERA NELL’ALTRO .BAK!”

II. Il Pozzo dei Commentatori di Codice

Programmatori che invece di cancellare codice vecchio lo commentano “per sicurezza”, creando migliaia di righe di codice zombie.

// function vecchia() {
// // non cancellarla mai
// // potrebbe servire
// // chi lo sa
// }

Pena: Leggere all’infinito codice commentato cercando di capire quale pezzo sia ancora in uso, mentre il codice commentato si moltiplica più velocemente di quanto possano leggere.

III. La Palude dei Maledetti composer.json

Il cerchio più profondo. Qui dimorano coloro che:

• Copiano composer.json invece di fare branch
• Creano composer.json.bak245p8bis (BIS! C’ERA GIÀ UN .bak245p8!)
• Usano anche un altro pattern per fare la copia di composer.lock e ti buttano li in scioltezza un composer-lock
• Fanno composer update in produzione alle 3 di notte
• Committano vendor/ nel repository

Pena: Condannati a risolvere dependency conflict infiniti mentre ogni loro composer install installa versioni random di librerie incompatibili tra loro. Il comando composer update impiega 40 giorni e alla fine fallisce sempre con “Your requirements could not be resolved”.

IL PECCATO SUPREMO: Il Caso Magento 2

Ma c’è di peggio. Oh, c’è MOLTO di peggio.

Perché questa non è una codebase qualunque. Questa è Magento 2.

E questi maledetti hanno commesso il peccato imperdonabile: hanno installato lo stesso modulo (Amasty_CheckoutThankYouPage) in DUE POSTI DIVERSI:

• Una volta tramite Composer in vendor/
• Una volta copiato manualmente in app/code/

Il risultato?

Autoload error: Module 'Amasty_CheckoutThankYouPage' from '/var/www/html/app/code/Amasty/CheckoutThankYouPage' 
has been already defined 

Magento non sa quale usare. Io non so quale sia aggiornato. Dio stesso ha perso la speranza.

Ora dovrò passare ORE a:

1. Controllare quale versione è in vendor/
2. Controllare quale versione è in app/code/
3. Verificare quale è quella “vera”
4. Capire se le dipendenze in composer.lock corrispondono a quello che c’è realmente
5. Scoprire quali altri moduli sono duplicati
6. Piangere silenziosamente
7. Bestemmiare rumorosamente
8. Scrivere questo pamphlet

Questo è il vero inferno: non solo non hanno usato git, ma hanno violato la regola fondamentale di Magento 2: O composer O app/code/, MAI ENTRAMBI PER LO STESSO MODULO.

L’Accusa Formale

Io accuso questi programmatori di:

1. Crimini contro l’Umanità Digitale: Aver reso impossibile capire quali modifiche sono state fatte, quando, e perché.
2. Tradimento della Fiducia: Git esiste dal 2005. DUEMILA-CINQUE. Vent’anni per imparare git add, git commit, git push. Non è chiedere troppo.
3. Pigrizia Attiva: Perché copiare un file e rinominarlo richiede più sforzo che fare un commit. È pigrizia che genera lavoro extra. È pigrizia inefficiente. È la peggiore forma di pigrizia.
4. Assassinio della Collaborazione: Come dovrebbe lavorare un team quando il “version control” consiste nel leggere i nomi dei backup come foglie di tè?
5. Devastazione del Composer.json: Un file elegante, semplice, che dichiara le dipendenze del progetto. Ridotto a un arlecchino di backup incomprensibili.
6. Doppia Installazione dei Moduli: Il crimine più grave in Magento 2. Installare lo stesso modulo sia via Composer che copiandolo in app/code/. Questo non è solo ignoranza. È sabotaggio attivo.

La Sentenza

Git non è un optional. Non è “roba da smanettoni”. Non è “complicato”.

È il MINIMO sindacale della professione.

È come un idraulico che non sa dove si chiude l’acqua.

È come un elettricista che non sa distinguere fase e neutro.

È come un chirurgo che dice “i guanti? Mah, se ho tempo”.

Appello alle Generazioni Future

Giovani sviluppatori, ascoltate bene:

• Non copiate mai file sorgente per “tenerli da parte”
• Git è vostro amico: ogni modifica merita un commit
• I branch esistono: usateli invece di creare file paralleli
• Composer.lock è sacro: va committato, non duplicato
• Vendor/ non va committato: MAI

E se un giorno vi trovate a scrivere composer.json.bak2:

FERMATEVI.

Respirate.

Fate quel commit che state rimandando.

Non diventate anche voi abitanti del nono cerchio.

Post Scriptum

Al collega dev stolto che ha creato .bak245p8bis:

Ti perdono.

Ma solo dopo che avrai fatto un corso di git.

E una confessione pubblica su Stack Overflow.

E 100 ore di community service sistemando repository aziendali.

«Lasciate ogne speranza, voi ch’intrate…

…in una codebase senza git»

Fine del J’accuse

Al recente DrupalCamp Italy ho scelto di parlare di Drupal Canvas, dopo averlo visto presentare in grande stile alla DrupalCon di Vienna, con ben due talk dedicati.

A Roma ho avuto anche modo di incontrare Michaël Fanini e Pierre Dureau del team UI Suite e di seguire il loro intervento “Display Builder, il visual builder nativo dei design system di UI Suite”.

Due approcci, stesso problema da risolvere

Canvas e Display Builder, pur con approcci diversi, provano a risolvere lo stesso problema: ridurre la dipendenza dai tempi dei developer nella modellazione delle pagine e dare più autonomia operativa ai site builder.

In un mondo in cui strumenti come Squarespace, Webflow e Framer permettono anche a chi non scrive codice di ottenere pagine perfettamente funzionanti, i CMS tradizionali fanno ancora fatica a tenere il passo.

In pratica si tratta di ridurre tempi e passaggi di mano tra:

• il design concepito (spesso in Figma),
• la definizione di componenti riutilizzabili,
• la costruzione effettiva delle pagine nel CMS.

Un déjà-vu dal mondo WordPress

Esattamente un anno fa ho seguito come consulente un team che, per alcuni progetti WordPress, mi chiedeva proprio questo: come ridurre la distanza tra l’output di Figma e la creazione di componenti riutilizzabili nel sito.

Lì i page builder non mancano di certo: Elementor, Gutenberg, WPBakery, e molti altri. Forse sono persino troppi, ma la direzione è chiara: meno attrito tra design e contenuto.

Ora è il turno di Drupal

Oggi anche Drupal è pronto per questo salto. Sia Canvas che Display Builder consentono di recepire e utilizzare Design System definiti altrove (ad esempio in uno Storybook) e portarli più vicino a chi costruisce pagine ogni giorno.

Il risultato atteso è chiaro: loop di feedback più brevi e maggiore velocità nel trasformare il design in pagine reali.

Il mio talk al DrupalCamp Italy è stato l’occasione per mettere questi temi sul tavolo e confrontarmi con la community. Ecco un po’ di materiale:

• le slide del talk: https://docs.google.com/presentation/d/1p-bVbkM_BKPtJe8U4ZI8DISVrBkWuGtvpM5smstYR-Y/edit?usp=sharing
• la registrazione del talk: https://www.youtube.com/watch?v=rowFutR1980&list=PL9purqp7U2jxr0mE-Q5TA-8eThiGQ7gIv&index=13
• i due repository Git utilizzati per le demo:
  • https://github.com/erighetto/DrupalCampRome2025-Canvas
  • https://github.com/drupalforge/drupal_cms_xb_demo
    

Negli ultimi anni la ricerca full-text è diventata uno dei pilastri dell’esperienza utente in Drupal.
Moduli come Search API, Facets, Better Exposed Filters e Views Autocomplete Filters permettono di realizzare ricerche dinamiche, con filtri e suggerimenti, anche su database di grandi dimensioni.

Per anni, la tecnologia più usata come motore di ricerca esterno è stata Elasticsearch, grazie alle sue performance e alla piena integrazione con Search API.
Ma dopo il cambio di licenza da parte di Elastic Inc., la community open source ha trovato in OpenSearch l’alternativa più naturale.

In pratica, OpenSearch nasce da Elasticsearch 7.10, ne mantiene la compatibilità e ne amplia le funzionalità, ma con un approccio open e trasparente.
Per Drupal, questo significa continuità nelle API e piena interoperabilità con la logica di Search API.

Perché passare a OpenSearch

1. Licenza open-source

OpenSearch è distribuito sotto licenza Apache 2.0, che consente l’uso e la modifica libera anche in contesti commerciali.
Non servono abbonamenti o licenze enterprise per attivare funzioni di sicurezza o gestione avanzata del cluster.

2. Compatibilità nativa con Drupal

Il modulo search_api_opensearch fornisce un backend dedicato a OpenSearch, completamente compatibile con Search API, Facets, Better Exposed Filters e Views Autocomplete Filters.
Non è un fork improvvisato, ma un progetto stabile mantenuto in parallelo alla piattaforma OpenSearch.

3. Sicurezza integrata

OpenSearch include nativamente TLS, autenticazione HTTP Basic, API Key, ruoli e permessi granulari (RBAC), oltre ad audit logging e supporto per CA interne.

4. Continuità tecnologica

La sintassi delle query, il DSL, i mapping e gli analyzer sono equivalenti a quelli di Elasticsearch 7.x.
Le applicazioni Drupal che già funzionano con Elasticsearch possono passare a OpenSearch senza modificare il codice.

5. Ecosistema in crescita

La community OpenSearch evolve rapidamente: alerting, SQL, kNN, anomaly detection e osservabilità sono oggi parte integrante del core.

Come passare a OpenSearch in Drupal

Il passaggio è più semplice di quanto sembri.
Ecco una procedura standard, indipendente dal contesto specifico.

1. Verifica la compatibilità del tuo stack

I moduli dell’ecosistem Search API sono tantissimi ma quelli che sono in relazione con la ricerca full-text sono in genere questi:

dependencies:
  - search_api:search_api
  - facets:facets
  - better_exposed_filters:better_exposed_filters
  - views_autocomplete_filters:views_autocomplete_filters
  - snowball_stemmer:snowball_stemmer

Tutti questi moduli restano compatibili: operano sopra Search API, quindi il cambio di backend non li coinvolge.

2. Sostituisci il backend Elasticsearch con OpenSearch

Installa il nuovo modulo:

composer require drupal/search_api_opensearch:^2
composer remove drupal/elasticsearch_connector

Poi, in Configurazione → Search API → Server, crea un nuovo server con backend OpenSearch.

• URL: https://opensearch.tuodominio.it:9200
• Autenticazione: Basic auth o API key
• Verifica TLS: se usi una CA interna, installala sul server Drupal o usa un reverse proxy con certificato trusted.

3. Definisci un pattern dedicato per gli indici Drupal

Per evitare conflitti con altri template o indici di sistema, usa un pattern dedicato (drupal-*).

Puoi creare su OpenSearch un Index Template con analyzer e filtro linguistico personalizzati, ad esempio per l’italiano:

curl -u admin:password \
  -H 'Content-Type: application/json' \
  -X PUT 'https://opensearch.tuodominio.it:9200/_index_template/drupal-template' -d @- <<'JSON'
{
  "index_patterns": ["drupal-*"],
  "template": {
    "settings": {
      "index": {
        "number_of_shards": 1,
        "analysis": {
          "analyzer": {
            "it_text": {
              "type": "custom",
              "tokenizer": "standard",
              "filter": ["lowercase", "asciifolding", "italian_stop", "italian_snowball"]
            }
          },
          "filter": {
            "italian_stop":    { "type": "stop",    "stopwords": "_italian_" },
            "italian_snowball":{ "type": "snowball","language":  "Italian"  }
          }
        }
      }
    }
  },
  "priority": 100
}
JSON

Se preferisci gestire lo stemming in Drupal (tramite snowball_stemmer), puoi omettere la sezione analysis.

4. Ricostruisci gli indici

Ricollega gli Index Search API al nuovo server OpenSearch e avvia la reindicizzazione.
Drupal ricreerà gli indici drupal-* da zero nel cluster OpenSearch, applicando il template appena definito.

5. Verifica le pipeline e le policy di lifecycle

• Se non usavi ingest pipeline, non devi configurare nulla.
• Se in Elasticsearch avevi ILM (Index Lifecycle Management), in OpenSearch troverai l’equivalente ISM (Index State Management).
  Le policy vanno ricreate, ma la logica di rollover e retention resta la stessa.

Risultato finale

Dopo la migrazione:

• Drupal continua a usare Search API, Views e Facets esattamente come prima.
• Tutte le query funzionano grazie alla compatibilità delle API.
• OpenSearch fornisce HTTPS, sicurezza integrata e licenza libera.
• L’indicizzazione è spesso più veloce grazie al miglioramento del cluster OS 2.x.

Bonus tip: OpenSearch in locale con DDEV

Se utilizzi DDEV per lo sviluppo in locale, aggiorna anche il servizio di ricerca passando dall’addon Elasticsearch a quello OpenSearch.

• Rimuovi l’addon Elasticsearch

  ddev delete addon ddev/ddev-elasticsearch
  ddev restart

• Installa l’addon OpenSearch

  ddev get ddev/ddev-opensearch
  ddev restart

URL utili

• Addon DDEV Elasticsearch (da rimuovere): ddev/ddev-elasticsearch
• Addon DDEV OpenSearch (da installare): ddev/ddev-opensearch

Dove puntare Drupal: all’interno del container PHP l’endpoint tipico è http://opensearch:9200; dal browser, l’istanza è normalmente esposta su https://opensearch.ddev.site:9200.

Conclusione

OpenSearch non è più soltanto il “fork” di Elasticsearch: oggi è una piattaforma completa, libera e in costante evoluzione.
Per i progetti Drupal rappresenta una scelta sostenibile, a prova di futuro, per mantenere prestazioni e funzionalità di ricerca avanzate senza vincoli di licenza o costi enterprise.

Se stai pianificando la migrazione del tuo motore di ricerca in Drupal — o vuoi valutare una configurazione ibrida con OpenSearch — contattami.

Ho raccolto in un post pubblicato su Linkedin alcuni insegnamenti che questo 2020 mi ha regalato.

https://www.linkedin.com/pulse/le-dieci-cose-che-ho-imparato-questa-prima-parte-di-2020-righetto

Parliamo di:

• Magento 2
• RabbitMQ
• Selenium WebDriver
• Siti html statici
• RequireJS
• Leaflet
• Analisi dei log

Buona lettura.

UnderStrap combines the Underscores starter theme (by Automattic) and the mobile-first, responsive grid framework Bootstrap 4 (by Twitter) into a perfect open source foundation for your next WordPress theme project.

In passato avevo già affrontato l’argomento:

Temi per WordPress

ma le tecnologie si evolvono e si aggiornano.
UnderStrap mette a disposizione dello sviluppatore WordPress l’ultima release del framework Bootstrap per la realizzazione di theme custom.

Se avete dimestichezza con Symfony avrete sicuramente imparato ad amare la versatilità di Monolog, scritto dallo stesso sviluppatore che ha inventato Composer.
Monolog supporta canali (Channels) di log differenti, ciascuno dei quali associati a degli Handler che sono in grado di scrivere un messaggio di log sulle destinazioni più disparate, da un semplice database passando per Syslog fino a soluzioni più evolute come postare un messaggio su Slack o Logstash.

Utilizzando un handler di Monolog possiamo interfacciarci con Amazon CloudWatch che è un servizio di monitoraggio per le risorse cloud AWS e le applicazioni in esecuzione su AWS. Si può utilizzare Amazon CloudWatch per raccogliere e monitorare parametri e file di log, impostare allarmi e reagire automaticamente ai cambiamenti nelle risorse AWS.

Quindi andiamo per ordine:

• per poter scrivere i nostri log dentro la piattaforma CloudWatch abbiamo bisogno di installare il wrapper di Monolog per Drupal 8
  composer require drupal/monolog:^1.0
• sucessivamente dovremo installare l’handler specifico per CloudWatch
  composer require maxbanton/cwh:^1.0
• nella stessa directory del file settings.php del sito dovremo creare uno specifico file per il servizio (monolog.services.yml per esempio) e poi aggiungere questa riga di codice nel file settings.php stesso:
  $settings['container_yamls'][] = 'sites/default/monolog.services.yml';

Ora abbiamo due possibili strade, la cui scelta dipende solo dalle specifiche esigenze del progetto.

Tutti i channel vengono scritti in un unico stream

Nel file sites/default/monolog.services.yml mettiamo queste impostazioni sostituendo i parametri che iniziano con my_ che sono solamente dei segnaposto.

--- 
parameters: 
  monolog.channel_handlers: 
    default: 
      - cloudwatch_handler

  monolog.processors: 
    - message_placeholder
    - current_user
    - request_uri
    - ip
    - referer

services: 
  cloudwatch_client: 
    class: Aws\CloudWatchLogs\CloudWatchLogsClient
    arguments: 
      - 
        credentials: 
          key: my_amazon_accesskey
          secret: my_amazon_secretkey
        region: my_amazon_region
        version: latest

  cloudwatch_handler: 
    class: Maxbanton\Cwh\Handler\CloudWatch
    arguments: 
      - "@cloudwatch_client"
      - my_group_name
      - my_stream_name
      - 30
      - 10000
      - 
        mytag: tag
      - DEBUG

Ogni channel di Monolog verrà scritto in uno specifico stream

Se vogliamo fare in modo che ogni channel, magari per una migliore leggibilità dei log, venga scritto in un proprio stream dobbiamo prima creare un handler custom che possiamo mettere in un modulo creato appositamente oppure in un altro modulo custom. Occhio solo a mettere il namespace corretto.

<?php

namespace Drupal\my_custom_module\Logger\Handler;

use Aws\CloudWatchLogs\CloudWatchLogsClient;
use Maxbanton\Cwh\Handler\CloudWatch;
use Monolog\Handler\AbstractProcessingHandler;
use Monolog\Logger;

/**
 * Class CloudWatchHandler
 *
 * @package Drupal\my_custom_module\Logger\Handler
 */
class CloudWatchHandler extends AbstractProcessingHandler {

  /**
   * CloudWatch constructor.
   */
  public function __construct() {
    parent::__construct(Logger::DEBUG, TRUE);
  }

  /**
   * Writes the record down to the log of the implementing handler
   *
   * @param  array $record
   *
   * @return void
   */
  protected function write(array $record) {

    $sdkParams = [
      'region' => "my_amazon_region",
      'version' => "latest",
      'credentials' => [
        'key' => "my_amazon_key",
        'secret' => "my_amazon_secret",
      ],
    ];

    $client = new CloudWatchLogsClient($sdkParams);

    $group = "my_group_name";

    if (empty($record['channel'])) {
      $stream = "default";
    }
    else {
      $stream = $record['channel'];
    }

    /** @var  \Maxbanton\Cwh\Handler\CloudWatch $handler */
    $handler = new CloudWatch($client, $group, $stream, 30, 10000, [], Logger::DEBUG);

    $handler->write($record);
  }

}

A questo punto nel nostro file sites/default/monolog.services.yml mettiamo le configurazioni:

--- 
parameters: 
  monolog.channel_handlers: 
    default: 
      - cloudwatch_handler

  monolog.processors: 
    - message_placeholder
    - current_user
    - request_uri
    - ip
    - referer

services: 
  cloudwatch_handler: 
    class: Drupal\my_custom_module\Logger\Handler\CloudWatchHandler   
    #Modificare con il namespace corretto

Come si può notare il servizio è molto spartano, ma può essere ampliato iniettando come argomento magari \Drupal\Core\Config\ConfigFactoryInterface $config_factory per caricare una configurazione oppure \Drupal\Core\Entity\EntityTypeManager $entity_type_manager per interfacciarsi con il repository di un’entità.

quale è il modo più semplice in un progetto Drupal per gestire le variabili di ambiente?

Le ultime versioni di Drupal Console includono una feature molto utile per gestire le variabili che hanno valori che possono variare tra i diversi ambienti come parametri di connessione al db o path dell’installazione.

Questo è possibile tramite una libreria che è una dipendenza di drupal-console: https://github.com/vlucas/phpdotenv.
In pratica ce lo troviamo già nelle nostre disponibilità senza fare nulla.
Vediamo quindi come utilizzarlo, anche in un progetto già avviato.

drupal dotenv:init

Nella shell ci verrà chiesto di immettere alcuni valori, come i parametri di accesso al db: nome, utente, password.
Drupal Console creerà un file .env nella root e modificherà il file web/sites/default/settings.php per fare in modo che le variabili presenti nel file .env vengano lette.
Questo è un esempio di .env

# ENV
ENVIRONMENT=stage

# DATABASE
DATABASE_NAME=drupal
DATABASE_USER=drupal
DATABASE_PASSWORD=aUVOicUSmS9Zn9SiW6zB
DATABASE_HOST=localhost
DATABASE_PORT=3306

# PATH
ROOT=/var/www/demowebsite.it/web

# SETTINGS

Se lavoriamo in collaborazione con altri sviluppatori possiamo creare anche un file di distribuzione .env.dist con i valori di default da includere nel repository git.

L’utilizzo più comodo che ci viene gratis è fare in modo che anche il nostro file .aliases legga il file .env così non dobbiamo sempre settare i path quando lanciamo un comando drush, drupalconsole oppure robo:

#!/bin/bash
export $(egrep -v '^#' .env | xargs)
alias drush="vendor/bin/drush -r $ROOT"
alias drupal="vendor/bin/drupal --root=\"$ROOT\""
alias robo="vendor/bin/robo"

Come dicevo anche il task runner Robo, può leggere le variabili di ambiente dichiarate in .env.

Ecco un semplice esempio:

/**
* RoboFile constructor.
*/
public function __construct() {
  $dotenv = new \Dotenv\Dotenv(__DIR__);
  $dotenv->load();
  $this->environment = getenv('ENVIRONMENT');
}