Negli ultimi interventi di ottimizzazione eseguiti sui server hosting gestiti da LandLogic IT, abbiamo individuato una problematica spesso sottovalutata negli ambienti con molti siti WordPress, WooCommerce e applicazioni web dinamiche: l’utilizzo di tabelle database in formato MyISAM invece di InnoDB.

In diversi casi i server presentavano:

• rallentamenti improvvisi dei siti
• timeout casuali
• backend WordPress molto lenti
• picchi anomali di CPU e I/O
• blocchi temporanei di PHP-FPM
• accesso rallentato anche al pannello Plesk

Dopo un’analisi approfondita del motore database MariaDB, abbiamo identificato numerose tabelle legacy ancora configurate con motore MyISAM.

Perché MyISAM può creare problemi nei server moderni

MyISAM è un motore storico di MySQL, nato in un’epoca molto diversa dagli attuali ambienti hosting.

Il problema principale è che utilizza il cosiddetto “table locking”: quando una query scrive dati, l’intera tabella viene bloccata.

In ambienti con:

• molti siti contemporaneamente attivi
• WooCommerce
• plugin che scrivono continuamente nel database
• cron automatici
• campagne Google Ads
• traffico elevato

questo comportamento può generare code di query, processi PHP in attesa e saturazione delle risorse server.

Il risultato è un effetto domino:

• query bloccate
• PHP-FPM congestionato
• aumento utilizzo CPU
• timeout nginx/apache
• siti temporaneamente irraggiungibili

La soluzione adottata

Abbiamo effettuato:

• scansione completa dei database
• identificazione delle tabelle MyISAM
• verifica compatibilità applicativa
• conversione controllata verso InnoDB
• ottimizzazione dei servizi database
• verifica dei plugin che generavano carico eccessivo

InnoDB offre numerosi vantaggi:

• locking a livello di singola riga
• migliore gestione concorrente delle query
• recovery automatica in caso di crash
• maggiore stabilità
• migliore utilizzo di RAM e SSD/NVMe
• performance superiori nei workload moderni

Risultati ottenuti

Dopo la migrazione:

• riduzione dei blocchi database
• backend WordPress più reattivi
• minori timeout PHP
• carico server più stabile
• miglior utilizzo delle risorse
• maggiore affidabilità generale dell’hosting

In ambienti multi-sito, anche piccoli dettagli infrastrutturali possono fare una grande differenza sulle performance complessive.

Ottimizzazione hosting: non conta solo la CPU

Molto spesso si pensa che i rallentamenti dipendano soltanto dalla potenza del server.

In realtà entrano in gioco molti fattori:

• motore database
• configurazione PHP-FPM
• plugin WordPress
• cache
• Redis
• gestione query SQL
• I/O disco
• configurazione MariaDB
• numero di processi concorrenti

L’ottimizzazione reale richiede un’analisi completa dell’intero stack applicativo.

Conclusioni

L’aggiornamento da MyISAM a InnoDB rappresenta ancora oggi uno degli interventi più efficaci per migliorare stabilità e performance nei server hosting moderni.

Su ambienti con molti siti WordPress, WooCommerce o applicazioni business, questa differenza può incidere concretamente sull’esperienza utente e sulla continuità operativa.

– Contattaci: per approfondimenti e info tecniche.

Negli ultimi giorni abbiamo riscontrato un comportamento critico su un ambiente Windows 11 Pro aggiornato con Docker Desktop 4.73.

Dopo l’aggiornamento:

• Docker Desktop non si avviava più;
• i processi com.docker.* comparivano e sparivano immediatamente;
• la distribuzione WSL2 docker-desktop-data risultava nello stato Uninstalling;
• tutti i container, le immagini e i volumi sembravano scomparsi.

Nel nostro caso erano coinvolti oltre 100 GB di dati Docker tra:

• container persistenti,
• database PostgreSQL/MariaDB,
• ambienti Odoo,
• stack Docker Compose,
• immagini personalizzate.

Fortunatamente il file VHDX contenente i dati era ancora presente e recuperabile.

La causa

Durante l’aggiornamento alla versione 4.73, Docker Desktop ha abilitato automaticamente la funzionalità:

Use containerd for pulling and storing images

Questa opzione introduce il nuovo image store basato su containerd e modifica il modo in cui Docker Desktop gestisce:

• immagini,
• snapshot,
• metadata,
• runtime storage.

Nel nostro caso la migrazione non è stata completata correttamente, lasciando WSL2 in uno stato incoerente.

Sintomi riscontrati

• Docker Desktop non si avvia
• docker-desktop-data in stato Uninstalling
• nessun container visibile
• backend Docker che crasha subito
• reinstallazione che non corregge il problema

Procedura di recupero adottata

1. Backup immediato del file .vhdx
2. Arresto completo WSL2
3. Disinstallazione controllata di Docker Desktop
4. Installazione Docker Desktop 4.72
5. Disabilitazione della funzione containerd image store
6. Ripristino manuale del file docker_data.vhdx
7. Riavvio ambiente WSL2

Dopo il ripristino:

• tutti i container,
• le immagini,
• i volumi persistenti

sono tornati operativi senza perdita dati.

Considerazioni tecniche

Questo episodio conferma quanto sia importante:

• effettuare backup dei file VHDX WSL2;
• evitare aggiornamenti immediati in ambienti critici;
• testare nuove release Docker Desktop;
• mantenere dump indipendenti dei database;
• valutare l’uso diretto di Docker Engine su Linux.

Per workload professionali persistenti, Linux rimane generalmente più prevedibile e stabile rispetto al layer Docker Desktop su Windows.

Conclusione

Docker Desktop resta uno strumento estremamente utile per sviluppo e test, ma quando vengono introdotte modifiche profonde al backend storage/runtime, è fondamentale prestare attenzione agli aggiornamenti automatici e alle migrazioni containerd.

Nel nostro caso il backup preventivo del file VHDX ha evitato una potenziale perdita di oltre 100 GB di ambienti containerizzati.

– Contattaci: per approfondimenti e info tecniche.

Come LandLogic ha reso il driver open-source di MagicTrackpad2ForWindows sicuro, attendibile e pronto per ambienti aziendali con Windows 11

Chi lavora con Mac e Windows in parallelo conosce bene la frustrazione di non poter utilizzare il Magic Trackpad di Apple su Windows con la stessa fluidità e ricchezza di gesture offerta su macOS. Il progetto open-source MagicTrackpad2ForWindows, sviluppato da Vito Plantamura e disponibile su GitHub (https://github.com/vitoplantamura/MagicTrackpad2ForWindows), risolve brillantemente questo problema: un driver Windows completo per Magic Trackpad 2, con supporto multi-touch, gesture avanzate e compatibilità sia USB che Bluetooth.

Il codice è tecnicamente solido e ben mantenuto. Tuttavia, per chi gestisce la sicurezza informatica di un’organizzazione, un driver non firmato o firmato senza certificati riconosciuti rappresenta un rischio inaccettabile: Windows mostra avvisi di sicurezza, i criteri di group policy possono bloccarne l’installazione e, soprattutto, non vi è alcuna garanzia di integrità verificabile sul software installato.

La soluzione LandLogic: firma EV Code Signing + Microsoft Attestation

LandLogic ha preso in carico la distribuzione certificata di questo driver, occupandosi dell’intera catena di firma e validazione. Il processo si articola in due passi fondamentali:

1. Firma con certificato EV Code Signing

LandLogic è in possesso di un certificato Extended Validation (EV) Code Signing rilasciato da una Certification Authority riconosciuta a livello globale. I certificati EV rappresentano il livello più alto di validazione per la firma del codice: richiedono una verifica rigorosa dell’identità legale dell’organizzazione firmataria e sono associati a un hardware security token fisico, rendendo praticamente impossibile la compromissione della chiave privata.

Con questo certificato LandLogic ha firmato:

• Il file del driver (.sys) di MagicTrackpad2ForWindows
• Il file eseguibile di gestione (.exe) incluso nel pacchetto

La firma EV garantisce che il software provenga inequivocabilmente da LandLogic e che non sia stato modificato dopo la firma. Windows SmartScreen riconosce immediatamente i certificati EV, eliminando gli avvisi di reputazione che normalmente compaiono per software nuovo o poco diffuso.

2. Microsoft Attestation Signing per Windows 11

La firma EV da sola non è sufficiente per i driver in modalità kernel su Windows 11. Microsoft ha introdotto il requisito di Attestation Signing: il driver deve essere inviato al Microsoft Hardware Dev Center, dove Microsoft verifica la firma EV del mittente e appone la propria firma di attestazione sul pacchetto del driver.

LandLogic ha completato questo processo: il driver firmato con EV è stato sottomesso al portale Microsoft per l’attestation e Microsoft ha restituito il driver con la propria firma ufficiale. Il risultato è un driver che:

• È riconosciuto come pienamente attendibile da Windows 11
• Non genera alcun avviso di sicurezza durante l’installazione, né via USB né via Bluetooth
• Può essere distribuito in ambienti aziendali con criteri di Secure Boot e Driver Signature Enforcement attivi
• È compatibile con le policy di group policy più restrittive

Perché questo è rilevante per la cybersecurity aziendale

I responsabili della sicurezza informatica sanno bene che i driver di dispositivo rappresentano uno dei vettori di attacco più critici in un sistema Windows. Un driver in modalità kernel opera con i massimi privilegi del sistema: un driver malevolo o non integro può compromettere l’intero sistema operativo, eludere gli antivirus e rendere vani tutti i controlli di sicurezza a livello applicativo.

Per questo motivo, la catena di fiducia nella distribuzione dei driver è fondamentale. Con il pacchetto LandLogic per MagicTrackpad2ForWindows, ogni responsabile IT e CISO dispone di evidenze concrete e verificabili:

• Identità del firmatario verificata tramite certificato EV (disponibile nell’elenco CRL/OCSP della CA)
• Controfirma Microsoft tramite Attestation, verificabile attraverso il portale Windows Hardware Compatibility
• Timestamp di firma crittograficamente vincolato, che garantisce la validità della firma anche dopo la scadenza del certificato
• Integrità del codice sorgente di partenza: il driver è basato sul repository pubblico di Vito Plantamura, consultabile e auditable da chiunque

Funzionalità del driver: cosa offre MagicTrackpad2ForWindows

Il driver firmato da LandLogic abilita su Windows 11 tutte le funzionalità avanzate del Magic Trackpad di Apple:

• Supporto multi-touch completo con gesture a più dita (scroll, pinch-to-zoom, rotazione)
• Compatibilità per Magic Trackpad 2 (A1535)
• Connessione sia via USB che via Bluetooth, senza differenze di funzionalità
• Applicazione di configurazione per personalizzare sensibilità, accelerazione e gesture
• Funzionamento silenzioso in background, senza impatto visibile sulle performance di sistema
• Nessuna dipendenza da software Apple aggiuntivi (nessun iTunes, nessun Bonjour richiesto)

Come ottenere il pacchetto LandLogic

Il pacchetto completo — comprendente il driver firmato Microsoft Attestation, l’eseguibile di gestione firmato EV e la documentazione di installazione — è disponibile direttamente sul sito del progetto github qui:
https://github.com/vitoplantamura/MagicTrackpad2ForWindows/releases/download/v2.0/MT2FW11-20260223-MSSigned.zip

Per ambienti enterprise con requisiti specifici di compliance, distribuzione tramite SCCM/Intune o necessità di documentazione aggiuntiva per audit di sicurezza, è possibile contattare il team LandLogic per un supporto dedicato.

Il codice sorgente originale su cui si basa il driver è verificabile pubblicamente al repository GitHub di Vito Plantamura: questa trasparenza, combinata con la catena di firma documentata, costituisce un elemento di fiducia verificabile end-to-end per qualsiasi processo di security review.

In sintesi

LandLogic distribuisce MagicTrackpad2ForWindows con la massima garanzia di sicurezza disponibile per driver Windows: firma EV Code Signing sull’identità dell’organizzazione e firma Microsoft Attestation sul driver, pienamente compatibile con Windows 11, Secure Boot e ambienti enterprise. Nessun avviso di sicurezza, nessuna eccezione da configurare.

– Contattaci: analizzeremo insieme la soluzione più adatta.

Un nuovo traguardo per l’integrazione hardware e software in ambienti Windows

Siamo lieti di annunciare che LandLogic è stata ufficialmente autorizzata da Microsoft all’accesso al Hardware Developer Program e al Hardware Dashboard del Partner Center.

Questo risultato ci consente di sviluppare, firmare e distribuire driver certificati per Windows in modo conforme alle linee guida Microsoft, garantendo ai nostri clienti i più alti standard di:

• sicurezza

• compatibilità

• affidabilità

• distribuzione controllata tramite ecosistema Microsoft

 – Firma digitale con certificato EV Code Signing

LandLogic è inoltre titolare di un certificato EV Code Signing (Extended Validation).

Questo significa che:

• i nostri eseguibili e componenti software sono riconosciuti come attendibili da Windows

• non vengono segnalati da SmartScreen come applicazioni sconosciute

• sono considerati validi dai principali sistemi antivirus e di sicurezza

• garantiscono l’integrità del codice distribuito ai clienti

Per le aziende questo si traduce in installazioni senza blocchi, maggiore fiducia e piena conformità alle policy IT.

 – Cosa cambia per i nostri clienti

Grazie a questa abilitazione possiamo:

Sviluppare driver personalizzati per dispositivi hardware

Per:

• periferiche USB e seriali

• dispositivi industriali

• sistemi embedded e IoT

• hardware professionale integrato in ambienti Windows

Firmare driver in modalità kernel secondo le policy Microsoft

Fondamentale per:

• Windows 10 e Windows 11

• ambienti con Secure Boot attivo

• infrastrutture aziendali gestite

Distribuire driver in modo sicuro e controllato

Attraverso:

• pacchetti firmati e verificati

• deployment aziendale

• eventuale distribuzione tramite Windows Update (quando richiesto)

 – Un vantaggio per system integrator e aziende

Molti produttori hardware non dispongono di competenze interne per:

• sviluppare driver Windows compliant

• gestire la firma kernel-mode

• superare i requisiti di sicurezza Microsoft

LandLogic si propone come partner tecnologico per:

• integrazione hardware/software

• sviluppo driver certificati

• testing di compatibilità con Windows

• distribuzione sicura in ambienti enterprise

 – Sicurezza, compliance e stabilità

L’accesso al programma Microsoft Hardware ci permette di operare secondo:

• Windows Driver Model (WDM / KMDF / UMDF)

• linee guida di sicurezza Microsoft

• processi di validazione e testing strutturati

Riducendo i rischi di:

• blocchi di installazione

• incompatibilità con aggiornamenti Windows

• problemi con Secure Boot e policy aziendali

 – Un ulteriore passo nella strategia LandLogic

Questo traguardo rafforza il nostro ruolo di:

• software house specializzata in integrazione con sistemi Windows

• partner per soluzioni enterprise e industriali

• riferimento per progetti che uniscono hardware, driver e software applicativo

Vuoi integrare un dispositivo hardware con Windows?

Se hai:

• un dispositivo che necessita di driver certificati

• un hardware che deve funzionare in ambienti aziendali protetti

• la necessità di distribuire software firmato e riconosciuto come sicuro

– Un ringraziamento speciale a Vito Plantamura [https://github.com/vitoplantamura/] per il contributo nello sviluppo avanzato e per la collaborazione tecnica che ha reso possibile rafforzare questa nuova area di competenza. 

– Contattaci: analizzeremo insieme la soluzione più adatta.

 Technical note for advanced users

LandLogic operates within the Microsoft Hardware Developer Program with access to the Hardware Dashboard for driver submission and signing workflows.

Our development and release process supports:

• Kernel-Mode and User-Mode drivers (KMDF / UMDF where applicable)

• Attestation signing for streamlined certification scenarios

• HLK/WLK validation workflows when full hardware certification is required

• Compatibility with Windows 10 and Windows 11, including systems with Secure Boot enabled

• Signed driver packages compliant with Microsoft distribution policies

All binaries are signed using an EV Code Signing certificate, ensuring:

• SmartScreen reputation trust

• integrity verification

• compliance with enterprise security policies

Driver deployment is performed through controlled enterprise channels or Microsoft’s driver distribution ecosystem, depending on project requirements.

This enables reliable integration of:

• USB / HID / Serial devices

• industrial and embedded hardware

• custom peripherals and control systems

within managed Windows infrastructures.

Quando Odoo Community e Enterprise non sono perfettamente allineati per commit, possono verificarsi errori critici.
Negli ambienti di produzione Odoo, soprattutto quando si utilizzano container Docker e moduli Enterprise, può sembrare sufficiente aggiornare all’ultima versione disponibile. In realtà, la compatibilità tra Odoo Community (core) e Odoo Enterprise (moduli commerciali) dipende in modo diretto dal commit Git preciso — e non solo dal numero di versione (es. 19.0).

– Il problema

Dopo aver aggiornato il container Docker Odoo Community alla build 19.0-20251021 (rilascio del 21 ottobre 2025) e i moduli Enterprise alla versione più recente disponibile (28 ottobre 2025), l’ambiente non riusciva più ad avviarsi correttamente.

ImportError: cannot import name 'ACCOUNT_CODES_ENGINE_SPLIT_REGEX'

Il modulo account_reports di Odoo Enterprise tentava di importare una costante che, nella nuova versione del core, non esisteva più.

– Analisi tecnica

L’errore non derivava da un problema di configurazione, ma da una mancata corrispondenza tra i commit. Tra il 21 e il 28 ottobre, Odoo SA aveva modificato il modulo account nel core, ma il corrispondente aggiornamento Enterprise era ancora in fase di sincronizzazione.

– La soluzione

Dopo vari test, la stabilità è stata raggiunta utilizzando i sorgenti Enterprise del 15 ottobre 2025, quindi leggermente più vecchi del core ma perfettamente compatibili con quella build Docker.

git fetch origin 19.0
git reset --hard `git rev-list -n 1 --before="2025-10-16" origin/19.0`

– Lezioni apprese

• Allineare sempre per data o commit, non per semplice branch.
• Evitare di aggiornare Docker e Enterprise in momenti diversi.
• Usare un controllo automatico per verificare la corrispondenza tra odoo --version e il commit Enterprise locale.
• Monitorare GitHub Issues: Issue #233611.

– Conclusione

Odoo è una piattaforma potente, ma estremamente integrata: piccoli disallineamenti tra moduli possono compromettere l’intero ambiente. Per chi gestisce installazioni in Docker o aggiornamenti CI/CD, la chiave è sincronizzare Community e Enterprise commit per commit.

Discussione su Reddit: link diretto al thread

Articolo a cura di Landlogic IT – Soluzioni Odoo e integrazione aziendale
www.landlogic.it

In uno dei nostri ambienti di produzione basati su Windows Server 2016, ci siamo trovati di fronte a un problema critico subito dopo l’installazione di un aggiornamento cumulativo: il server rimaneva bloccato nella schermata “Preparazione di Windows – Non spegnere il computer”, per poi riavviarsi in loop continuo.

Il comportamento era sintomo di un malfunzionamento del Component Store (WinSxS), il cuore del sistema di gestione aggiornamenti e componenti di Windows. In questo articolo spieghiamo come abbiamo diagnosticato e risolto il problema, riportando il server in stato operativo senza reinstallare l’ambiente.

– Analisi del problema

Durante l’avvio, il sistema non completava mai la fase di configurazione degli aggiornamenti e si riavviava ciclicamente. Nemmeno la modalità provvisoria o il ripristino automatico erano in grado di risolvere la situazione.

Abbiamo quindi avviato il server nell’ambiente di ripristino di Windows (WinRE) per operare con i comandi offline di manutenzione immagine.

dism /image:C:\ /cleanup-image /checkhealth
dism /image:C:\ /cleanup-image /restorehealth

Entrambi restituivano l’errore 0x800f081f, indicando l’impossibilità di trovare i file di origine necessari alla riparazione del sistema.

– Riparazione con DISM e ISO di Windows Server 2016

Per ripristinare il Component Store, abbiamo montato la ISO ufficiale di Windows Server 2016 tramite Lenovo XClarity Controller, rendendola disponibile come unità virtuale (E:).

dism /image:C:\ /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:2 /limitaccess /ScratchDir:C:\Scratch

Dopo diversi tentativi, il processo si è completato con successo:

“Operazione di ripristino riuscita.”

Questo ha ricostruito completamente il WinSxS e risolto le azioni di aggiornamento in sospeso che impedivano l’avvio del sistema.

– Caricamento dei driver RAID in ambiente di ripristino

Durante le prime fasi di diagnosi ci siamo accorti che, all’interno dell’ambiente di ripristino, Windows non caricava i driver del controller RAID installato nel sistema (nel nostro caso un ThinkSystem RAID 930-8i).

Questo comportava che i volumi logici non risultassero visibili con il comando diskpart → list volume, impedendo di accedere al disco del sistema (C:).

La soluzione è stata caricare manualmente i driver del controller:

1. Abbiamo scaricato dal sito Lenovo i driver più recenti del controller RAID.
2. Abbiamo estratto il pacchetto (file .exe) con 7-Zip, poiché i file di installazione non sono riconosciuti nativamente da WinRE.
3. All’interno dell’archivio, abbiamo individuato i file .INF necessari al caricamento manuale.
4. Abbiamo montato l’immagine ISO o IMG contenente i driver come unità virtuale tramite XClarity Controller.
5. Da prompt dei comandi di WinRE abbiamo eseguito:

   drvload E:\percorsi\driver\megaraid.inf

Dopo il caricamento, il comando wmic logicaldisk get name ha mostrato correttamente il volume C:, consentendoci di procedere con la riparazione tramite DISM.

Questo passaggio è fondamentale su hardware server con controller dedicati: senza il driver RAID, l’ambiente di ripristino non è in grado di accedere ai dischi e qualsiasi tentativo di manutenzione fallisce.

– Verifica e pulizia post-ripristino

Dopo la riparazione, abbiamo eseguito:

sfc /scannow

per verificare e ripristinare eventuali file di sistema danneggiati.

Successivamente, abbiamo pulito i componenti residui e rimosso versioni obsolete dei file:

dism /online /cleanup-image /startcomponentcleanup /resetbase

– Ripristino del database di Windows Update

Il tool di risoluzione problemi di Windows segnalava un errore nel “controllo del database di Windows Update”. Abbiamo quindi rigenerato manualmente la cache degli aggiornamenti rinominando le cartelle di sistema:

net stop wuauserv
net stop bits
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start bits

Questo ha permesso di ricreare un database pulito, eliminando riferimenti a patch corrotte o incomplete.

– Risultato finale

Dopo il riavvio, il server si è avviato correttamente senza più blocchi o loop di aggiornamento. Tutti i servizi di produzione sono tornati operativi e Windows Update è stato riallineato con il sistema.

• nessuna reinstallazione del sistema operativo;
• dati e configurazioni preservati;
• stabilità del sistema completamente ripristinata.

– Lezioni apprese e prevenzione

Abbiamo riscontrato che i loop post-aggiornamento su Windows Server 2016 derivano spesso da azioni pendenti nel processo di servicing. Per ridurre il rischio, consigliamo di:

• utilizzare strumenti come PSWindowsUpdate o WSUS Offline Update per applicare patch in modo transazionale;
• installare sempre prima il Servicing Stack Update (SSU) e poi il Cumulative Update (CU);
• eseguire periodicamente la pulizia del Component Store:

  dism /online /cleanup-image /startcomponentcleanup /resetbase

– Conclusione

Grazie a un intervento mirato con DISM, al caricamento manuale dei driver RAID e all’uso dell’immagine originale di Windows Server 2016 come sorgente, siamo riusciti a ripristinare completamente un sistema in produzione bloccato da un aggiornamento fallito.

L’esperienza conferma l’importanza di conoscere e utilizzare correttamente gli strumenti di manutenzione avanzata di Windows Server, in modo da prevenire fermi imprevisti e ridurre i tempi di downtime.

Il 20 novembre sarà disponibile Umbraco CMS 13.12, una release importante della serie LTS che porta con sé diversi miglioramenti di stabilità, performance e bug fix.
Tra questi, siamo orgogliosi di annunciare che è stato incluso il contributo di LandLogic per risolvere un problema storico del Media Picker.

– Il problema: cartelle lente con migliaia di file

Fin dalle versioni 10.x, il Media Picker di Umbraco caricava tutti gli elementi di una cartella in un’unica chiamata.
Per chi gestiva grandi librerie di immagini o documenti, questo causava:

• rallentamenti significativi nel backoffice,
• consumo elevato di RAM,
• e in alcuni casi, errori di timeout.

L’issue era stata segnalata nel 2022 e tracciata su GitHub come Issue #12364.

– La soluzione: paginazione lato client e prestazioni ottimizzate

Abbiamo analizzato il comportamento del Media Picker nella versione 13 e proposto una soluzione nel Pull Request #20202.

La nostra modifica:

• sostituisce l’uso di getChildren con getPagedChildren,
• introduce la paginazione lato client,
• e garantisce un caricamento progressivo delle immagini, riducendo drasticamente tempi e risorse usate.

Il tutto senza modificare l’API server e senza introdurre breaking changes.

– Un percorso open source reale

Durante la review, abbiamo collaborato con i maintainer ufficiali di Umbraco per affinare il codice e garantire compatibilità completa.
Grazie a questo confronto, il contributo è stato accettato e fuso nel core, e sarà distribuito nella release 13.12.

– Cosa cambia per chi usa Umbraco 13.x

• Il Media Picker ora gestisce correttamente la paginazione anche nelle cartelle con molti elementi.
• L’esperienza del backoffice è più fluida e reattiva.
• Nessuna modifica o configurazione richiesta: basta aggiornare alla 13.12.

– Disponibilità

La release Umbraco 13.12 sarà disponibile dal 20 novembre 2025.
Tutte le informazioni ufficiali e le note di rilascio sono disponibili su our.umbraco.com/releases/13120.

– Conclusione

Questo contributo dimostra come anche realtà italiane possano collaborare attivamente allo sviluppo di Umbraco CMS, migliorando l’esperienza per tutta la community.

Se la tua azienda utilizza Umbraco 13.x o precedenti, puoi contattarci per:

• ottimizzare performance,
• realizzare plugin o estensioni,
• o pianificare la migrazione verso Umbraco 14+.

Scopri di più su www.landlogic.it

Introduzione

Nel nostro lavoro quotidiano con Umbraco CMS ci siamo imbattuti in un problema fastidioso, presente fin dalla 10.x e mai risolto fino alla serie 13: il Media Picker caricava tutti gli elementi di una cartella, anche quando si trattava di centinaia o migliaia di file, causando rallentamenti e timeout.

Per dare una soluzione concreta alla community, abbiamo deciso di intervenire direttamente sul core.
Siamo partiti dall’issue #12364, aperta nel 2022 e rimasta senza fix per anni, abbiamo sviluppato una patch e l’abbiamo proposta come PR #20202.

Dopo un accurato processo di review con il team Umbraco, la nostra pull request è stata approvata e fusa: il fix sarà disponibile a partire da Umbraco 13.12.

Nota importante
La correzione interessa solo la serie 13.x (e versioni precedenti ancora supportate).
In Umbraco 14 e successivi il bug era già stato risolto nativamente nel core, quindi non serve applicare questa patch.

Sezione 1 — Il problema iniziale

Cosa succedeva
Quando si apriva il Media Picker in una cartella con molti file, l’interfaccia Angular richiamava un endpoint che restituiva tutti i figli senza paginazione.
Per cartelle con centinaia o migliaia di elementi questo significava:

• query pesanti sul database,

• grande consumo di RAM,

• possibili timeout lato browser e lato server.

Perché permane su 13.x
La serie 14 ha introdotto un Media Picker rinnovato che risolve automaticamente questa inefficienza.
Ma la 13.x è una LTS ancora molto diffusa, quindi il problema rimaneva per tutti i progetti che non possono passare subito alla major successiva.

Riferimenti

• Issue originale (aperta nel 2022): #12364

• Pull request di fix: #20202

Sezione 2 — Analisi e proposta di soluzione

File analizzati

• EntityController (back-office): endpoint GetChildren chiamato dal client.

• mediapicker.controller.js (front-end Angular): implementa le chiamate a entityResource.getChildren(...).

Diagnosi
Il problema non era a livello server ma nel front-end: il Media Picker non passava mai parametri di paging (skip, take), caricando sempre tutto.

Scelte valutate

1. Modifica lato server (limitare implicitamente i risultati): rischioso, potenziale breaking change.

2. Uso degli endpoint già esistenti di paging (getPagedChildren) nel client: sicuro, retro-compatibile.

Soluzione adottata

• Sostituzione di entityResource.getChildren(...) con entityResource.getPagedChildren(...), inviando pageNumber, pageSize e (solo se necessario) parametri di ordinamento.

• Introduzione di logica di paginazione lato front-end: reset della pagina quando si cambia cartella, gestione coerente anche durante la ricerca.

• Refactoring per ridurre la complessità ciclomatica: estratti piccoli helper, rimossi commenti temporanei, lasciati solo commenti tecnici chiari.

Sezione 3 — Il processo di review

Durante la review il team Umbraco, in particolare Andy Butland, ha svolto un lavoro molto accurato.
Alcuni punti chiave:

• Parametri inutili
  In una versione intermedia avevamo aggiunto orderBy: "VersionDate" e orderDirection: "Descending".
  Su richiesta di Andy li abbiamo rimossi, dato che il paging funziona correttamente con l’ordinamento di default.

• Commenti “da revisore”
  Alcune note come // MOD: o // helpers to reduce complexity sono state eliminate o sostituite con spiegazioni tecniche utili, ad esempio

  // reset filter to ensure folder navigation always starts unfiltered.

• Promise e ritorni coerenti
  La vera soluzione è stata rendere coerente la catena di promise (run(), ensureWithinStartNode(), gotoStartNode(), gotoFolder()), per garantire che la chiamata getPagedChildren sia sempre eseguita anche quando il Media Picker riapre direttamente nell’ultima cartella visitata.

• Formattazione
  Migliorata l’indentazione delle catene .then(...).finally(...) per maggiore leggibilità.

Grazie a questo confronto aperto, il codice finale è più solido, pulito e manutenibile.

Sezione 4 — Il risultato e i benefici per la community

• Performance migliorata
  Ora il Media Picker carica solo gli elementi della pagina corrente (es. 100 o 200 alla volta), con un impatto enorme su tempi di caricamento e memoria.

• Nessun breaking change
  Il back-end (EntityController) resta invariato: chi usa ancora getChildren non subisce alcun cambiamento.

• Codice più chiaro
  La gestione della paginazione è leggibile e documentata, facilitando la manutenzione futura.

• Valore per chi resta su Umbraco 13
  Le aziende che non possono migrare subito a 14 (o che sono ancora su 10–12) possono aggiornare tranquillamente a 13.12 e godere dei miglioramenti.

Sezione 5 — Cosa abbiamo imparato (e consigli pratici)

• Anche i piccoli bug contano: un’ottimizzazione del backoffice può migliorare la vita quotidiana di molti editori di contenuti.

• Dialogo costruttivo con i maintainer: ogni commento della review è stato un’occasione per semplificare e rafforzare il codice.

• Scrivere meno ma meglio: rimuovere codice inutile è spesso il miglior fix.

• Documentare il “perché”: spiegare le ragioni di un reset o di una scelta di design aiuta chi leggerà tra mesi o anni.

Conclusione e call to action

Siamo orgogliosi che la nostra PR #20202 sia stata accettata e inclusa ufficialmente nel core di Umbraco, a partire dalla versione 13.12.
Dopo quasi due anni dall’apertura dell’issue #12364, la community Umbraco ha finalmente una soluzione nativa e stabile.

Se utilizzi Umbraco 13.x (o versioni 10–12) e vuoi:

• migliorare le performance del backoffice,

• scrivere estensioni,

• o ricevere supporto per migrazioni complesse,

contattaci su landlogic.it: saremo felici di condividere la nostra esperienza e contribuire al successo del tuo progetto.

Dal codice alla gestione dei contenuti, una nuova era di automazione e assistenza per e-commerce e CMS.

Intro

In LandLogic siamo sempre alla ricerca di tecnologie che permettano di ridurre i tempi, aumentare la qualità e migliorare l’esperienza d’uso dei sistemi che sviluppiamo.
Negli ultimi mesi abbiamo avviato diversi progetti sperimentali basati sul Model Context Protocol (MCP), una nuova tecnologia che permette di collegare l’intelligenza artificiale direttamente alle funzionalità specifiche di un software, in modo sicuro e personalizzato.

Queste implementazioni sono attualmente in fase di sviluppo e ci consentiranno di offrire ai clienti strumenti AI “su misura”, perfettamente integrati con le piattaforme che utilizzano ogni giorno: nopCommerce, Umbraco, WordPress/WooCommerce e Odoo.

Cos’è MCP

Il Model Context Protocol è un protocollo che definisce come un’applicazione può esporre “tool” (funzioni specifiche) che l’AI può usare in tempo reale.
In pratica, il modello AI non lavora più “alla cieca”, ma sa come interrogare e utilizzare dati e funzioni reali del tuo sistema, rispettando regole di sicurezza e contesto.

Con MCP possiamo progettare:

• Operazioni mirate (es. “cerca prodotti per categoria”, “genera descrizione SEO”, “crea preventivo”).

• Accesso controllato a dati, API e logica di business.

• Integrazione trasparente e sicura delle funzionalità AI nei flussi aziendali.

Progetti in corso

nopCommerce

Stiamo sviluppando tool MCP che permetteranno di:

• Generare automaticamente descrizioni prodotto ottimizzate SEO.

• Creare meta-tag e testi marketing basati sulle specifiche tecniche.

• Effettuare ricerche avanzate in catalogo usando linguaggio naturale.

• Fornire assistenza nella gestione ordini (recupero stato, proposte di upselling).

Il tutto sarà integrato come plugin lato admin, con pulsanti e wizard direttamente nell’interfaccia di backoffice.

Umbraco

Su Umbraco, i tool MCP in lavorazione includono:

• Assistenza editoriale: suggerimenti per testi, riassunti e traduzioni.

• Generazione di contenuti multilingua a partire da una singola bozza.

• Estrazione automatica di keyword e meta description.

• Chat interna per redattori, collegata ai contenuti pubblicati.

L’integrazione avverrà come dashboard custom in backoffice.

WordPress/WooCommerce

Stiamo realizzando tool MCP che potranno:

• Analizzare e migliorare le schede prodotto.

• Creare automaticamente post blog con riferimenti al catalogo.

• Generare immagini AI coerenti con il brand.

• Suggerire aggiornamenti e cross-selling.

Tutto sarà accessibile dal classico editor di WordPress o dalla scheda prodotto WooCommerce.

Odoo

Su Odoo Enterprise 18, stiamo sviluppando sia funzioni ERP che CRM:

• Creazione rapida di preventivi partendo da una richiesta in linguaggio naturale.

• Ricerca prodotti, disponibilità e prezzi in tempo reale.

• Preparazione automatica di email commerciali pronte all’invio.

• Riassunti di ordini, fatture e movimenti di magazzino.

• Assistenza per supporto clienti con risposte contestualizzate sui dati ERP.

Queste funzionalità saranno disponibili direttamente in Odoo (tramite modulo Python MCP) o tramite un hub esterno integrato.

Perché stiamo investendo su MCP

• Velocità: riduzione drastica dei tempi per molte operazioni ripetitive.

• Qualità: contenuti e risposte basati su AI e dati reali.

• Personalizzazione: strumenti progettati sulle regole e sui processi del cliente.

• Sicurezza: accesso AI solo alle funzioni e ai dati autorizzati.

Conclusione

MCP non è “un’altra moda AI”, ma un nuovo modo di collegare in sicurezza l’intelligenza artificiale alla realtà dei dati aziendali.
Con questi progetti, attualmente in sviluppo, LandLogic sta portando automazione intelligente nei sistemi dei propri clienti, dal piccolo e-commerce al portale enterprise.

Vuoi scoprire come MCP potrà rivoluzionare il tuo sistema?
Contattaci: info@landlogic.it
oppure visita la sezione contatti su landlogic.it