DASHBOARD CLIENTE — AUDIT COMPLETO #

Data: 2026-05-13 Sessione: Step A della trasformazione dashboard (Fase 11) Obiettivo: mappare lo stato attuale per pianificare Step B (foundation) e Step C (hub-by-hub).

---

📊 1. INVENTARIO QUANTITATIVO #

File JavaScript (12.453 righe totali) #

REST routes (167 totali in 19 controller) #

Plus plugin hostwebo-billing: 4 REST controllers V2 (Checkout, Webhook, Invoice, Affiliate, Domain, Addon, Auth, Subscription, Welcome) ≈ 25 routes.

Menu attuale (16+ voci + V2 extension) #

Cluster A (core):
- overview          → views-overview.js (323 righe)
- hosting           → views-hosting.js (410 righe)  🟡 LEGACY
- domains           → views-domains.js (1544 righe)
- wp                → views-wordpress.js (661 righe)
- email             → views-email.js (908 righe)
- ai-assistant      → views-ai-assistant.js (390 righe)
- theme-studio      → views-theme-studio.js (2092 righe)
- ai-savings        → views-ai-savings.js (191 righe)
- backups           → views-backups.js (283 righe)
- services          → views-services.js (354 righe)
- service-orders    → views-service-orders.js (236 righe)
- my-quotes         → views-my-quotes.js (211 righe)

[separator]

Cluster B (account):
- tickets           → views-tickets.js (542 righe)
- billing           → views-misc.js (667 righe — partial)
- orders            → views-misc.js (partial)
- account           → views-misc.js (partial)

[V2 extension billing-dashboard.js]:
- il-mio-piano      🆕 nuova vista hero
- v2-fatturazione   🆕 vista billing completa V2
- v2-affiliazione   🆕 vista affiliazione cliente
- welcome           🆕 onboarding wizard (auto-navigate)

Totale voci attive sidebar: 19 (16 core + 3 V2 extension).

---

🔥 2. PERFORMANCE BASELINE (misurato live) #

Test eseguito su https://www.hostwebo.it/area-clienti/ con admin user (zero servizi attivi → endpoint vuoti):

📉 Avg: 1292 ms per endpoint vuoto.

Diagnosi performance #

Anche endpoint che ritornano [] impiegano oltre 1 secondo:

• ✅ Probabile causa 1: chiamate sincrone a Plesk anche quando l’utente non ha ancora un mapping
• ✅ Probabile causa 2: ogni handler fa autenticazione + permission_callback isolato
• ✅ Probabile causa 3: ZERO transient caching su 17/19 controller (solo hosting.php e shop.php usano caching)
• ✅ Probabile causa 4: nessun fast-path “user has nothing → return [] immediately”

Conseguenza UX: cambio sezione = 3-4 secondi di attesa cumulativa (1-3 chiamate per vista).

---

🔴 3. DUPLICAZIONI & CODICE MORTO #

Duplicazione 1 — Hosting (legacy Upmind vs V2) #

• views-hosting.js (410 righe) — legacy Upmind, mostra contracts via /hosting
• v2-billing-dashboard.js → vista il-mio-piano — nuovo Stripe-based

Verdetto: il-mio-piano è il futuro. views-hosting.js può essere rinominata o rimossa (la vista mostrerebbe ancora i contracts Upmind storici).

Duplicazione 2 — Billing (legacy vs V2) #

• views-misc.js (parte billing) — legacy Upmind invoices
• v2-billing-dashboard.js → vista v2-fatturazione — V2 fatture/pagamenti
• Sezione orders in views-misc.js — legacy
• 2 endpoint REST diversi: /billing/invoices vs /hostwebo-billing/v1/invoices/me

Verdetto: la sezione billing V2 è completa, collassare tutto sotto un hub Billing V2.

Duplicazione 3 — File Manager + Domini #

• views-files.js (959 righe) — File Manager standalone
• views-domains.js (1544 righe) — già include databases, cron, ftp per dominio

Verdetto: File Manager dovrebbe essere un tab dentro Domini (quando si gestisce un dominio specifico).

Codice morto / orfano #

---

🎯 4. FEATURE GAP vs DESIGN PROPOSTO #

Hub design proposto vs codice esistente #

Gap riassuntivo:

• 🆕 Attività recente in overview — fattibile da audit log esistente
• 🆕 Recipe Migrator vista dedicata (o sotto WP) — manca
• 🆕 FAQ AI integrato in supporto — hostwebo-ai/v1/knowledge-base esiste, va wired
• 🛠 Affiliazione: oggi voce sidebar separata, andrebbe sotto Account
• 🛠 2FA / sicurezza account: verificare implementazione esistente

---

⚡ 5. STRATEGIA TECNICA (per Step B) #

A. History API + URL reali #

Oggi:

/area-clienti/#hosting     ← hash fragment
/area-clienti/#billing

Domani:

/area-clienti/                ← Dashboard
/area-clienti/sito/           ← Il mio sito (default tab: WP)
/area-clienti/sito/domini/    ← Tab domini
/area-clienti/billing/        ← Billing (default tab: Il mio piano)
/area-clienti/billing/fatture/
/area-clienti/ai/             ← Hostwebo AI
/area-clienti/ai/theme-studio/
/area-clienti/marketplace/
/area-clienti/supporto/
/area-clienti/account/

Implementazione: History API pushState + popstate + WordPress rewrite rule che cattura /area-clienti/.* e ritorna sempre la stessa pagina (la SPA legge window.location.pathname invece di hash).

B. SSR first-paint via PHP #

Oggi: tutto vuoto al primo paint → skeleton → fetch → render (3-4s)

Domani:

// In page template, prima dello <script>
$bootstrap = array(
    'subscription' => ( new SubscriptionRepository() )->get_active_for_user( $user_id ),
    'overview_kpi' => ( new OverviewService() )->get_summary( $user_id ),
);
?>
<script>window.HWInitialData = <?php echo wp_json_encode( $bootstrap ); ?>;</script>

→ JS controlla window.HWInitialData e se presente skipa fetch iniziale. → First paint con dati: < 200ms invece di 1.3s.

C. Transient cache server-side #

Schema chiavi:

hwbi_plesk_limits_{user_id}     5 min   — disk/traffic/cpu
hwbi_wp_list_{user_id}          5 min   — installed WP sites
hwbi_domain_list_{user_id}      10 min  — registered domains
hwbi_email_list_{user_id}       10 min  — mailboxes
hwbi_overview_kpi_{user_id}     1 min   — dashboard hero
hwbi_my_sub_{user_id}           1 min   — subscription summary
hwbi_billing_kpi_{user_id}      5 min   — billing overview
hwbi_affiliate_stats_{user_id}  30 min  — slow-changing
hwbi_invoices_me_{user_id}      5 min   — paginated invoices

Invalidazione hook-based:

add_action('hwbi_order_paid',           [Cache::class, 'flush_user']);
add_action('hwbi_subscription_changed', [Cache::class, 'flush_user']);
add_action('hwbi_domain_registered',    [Cache::class, 'flush_user']);
add_action('hwbi_wp_installed',         [Cache::class, 'flush_user_wp']);
add_action('hwbi_invoice_issued',       [Cache::class, 'flush_user_billing']);
add_action('hwdash_email_created',      [Cache::class, 'flush_user_email']);

D. Fast-path “no provisioning” #

Aggiungere check all’inizio di ogni handler legacy:

public function handle_get_hosting() {
    $user_id = get_current_user_id();
    // FAST PATH: no Upmind mapping → return empty immediately
    if ( ! get_user_meta( $user_id, 'upmind_client_id', true ) ) {
        return new WP_REST_Response( array(), 200 );
    }
    // ... slow path
}

→ Endpoint vuoto: < 50ms invece di 1.3s.

E. Parallel fetching + prefetch #

Oggi (sequenziale):

HWApi.get('overview').then(d => render(d));
// Poi user clicca billing → fetch separata

Domani (parallel + prefetch):

Promise.all([
    HWApi.get('overview'),       // critical
    HWApi.get('my-sub')          // background
]).then(([overview, sub]) => render(overview, sub));

// Su mouseenter del menu billing → prefetch
button.addEventListener('mouseenter', () => HWApi.get('billing/invoices', { prefetch: true }));

---

📋 6. TODO LIST PER STEP B (Foundation) #

Priorità ordinate per ROI (impatto × velocità):

🔥 Quick wins immediati (Step B1 — 1-2h) #

1. Fast-path 404→200 sui handler che ritornano [] (5-10 line di codice per handler, risparmia 1+ sec)
2. Transient cache layer generic (1 classe utility, applicata ai 5 endpoint più hot)
3. Cache invalidation hooks centralizzati

🛠 Foundation refactor (Step B2 — 3-4h) #

1. Refactor menu da 16→7 hub in dashboard.js
2. Sub-tab system nel core: HWStore.section + HWStore.subTab
3. History API routing (pushState + popstate)
4. Page title sync <title> per ogni view

🚀 Performance polish (Step B3 — 2h) #

1. SSR window.HWInitialData dal template page-dashboard.php per overview + sub
2. Prefetch on hover sui menu item
3. Skeleton shape-matched per ogni hub

🧹 Cleanup (Step B4 — 1h) #

1. Remove views-credit.js (rimosso da menu, file orfano)
2. Remove modal Upmind redirect in views-hosting.js (Upmind decommissioned)
3. Verifica + rimozione checkout.js dashboard se non usato

---

📋 7. TODO LIST PER STEP C (Hub-by-hub) #

C1 — Hub “Il mio sito” (4-5 tab, ~3h) #

• Tab 1: WordPress (views-wordpress.js → conservare, polish)
• Tab 2: Domini (views-domains.js → splittare DNS/databases/cron/ftp in sub-tab)
• Tab 3: Email (views-email.js → polish)
• Tab 4: Backup (views-backups.js → polish)
• Tab 5: File Manager (views-files.js → integrare come tab di Domini quando dominio selezionato)
• Caching specifico: Plesk domain list 10min, WP list 5min, email list 10min
• Performance budget: first paint < 300ms via SSR

C2 — Hub “Hostwebo AI” (3-4 tab, ~3h) #

• Tab 1: Chat AI (views-ai-assistant.js → polish + quota visibility)
• Tab 2: Theme Studio (views-theme-studio.js → review 2092 righe, polish UI)
• Tab 3: Risparmio (views-ai-savings.js → polish + add comparison vs OpenAI/Claude)
• Tab 4: Recipe Migrator — NEW se manca, o integrato in WP
• Caching specifico: AI quota 1min, package info 30min
• Performance budget: Theme Studio è streaming, no cache; chat è streaming, no cache

C3 — Hub “Billing” (4 tab, ~2.5h) #

• Tab 1: Il mio piano (v2-billing-dashboard.js/il-mio-piano → polish)
• Tab 2: Fatture (estrarre da v2-fatturazione)
• Tab 3: Pagamenti (estrarre da v2-fatturazione)
• Tab 4: Storico ordini (migrare da views-misc.js/orders a V2 endpoint)
• Caching specifico: my-sub 1min, invoices 5min, payments 5min
• Migrazione: deprecare endpoint legacy /billing/invoices → puntare tutto a V2

C4 — Hub “Marketplace + Supporto + Account” (3 hub minori, ~2h) #

• Marketplace (3 tab): catalog, my services, quotes
• Supporto (2-3 tab): aperti, storico, FAQ AI (new wiring)
• Account (4 tab): profilo, sicurezza, affiliazione (migrata da voce a parte), notifiche
• Affiliazione: spostare da voce sidebar a tab Account

---

🎯 8. CRITERI DI ACCETTAZIONE #

Per dichiarare ogni Step “done”:

Step B done quando: #

• [ ] Menu sidebar mostra 7 hub primari (no più 16+ voci)
• [ ] URLs reali con History API (no più hash)
• [ ] Endpoint vuoti < 100ms (fast-path attivo)
• [ ] Endpoint cached < 50ms ripetuti (cache hit verificato)
• [ ] First paint dashboard < 500ms (SSR bootstrap)
• [ ] views-credit.js rimosso, no warning console
• [ ] checkout.js valutato (rimosso o documentato perché serve)

Step C done quando (per hub): #

• [ ] Tab interno funzionante con state persistente
• [ ] Cache attiva su tutti gli endpoint dell’hub
• [ ] Skeleton shape-matched al render finale
• [ ] Test live: navigazione tra tab < 200ms
• [ ] Prefetch on hover attivo
• [ ] Audit log eventi cliente registrato

---

📝 9. RISCHI & MITIGATIONS #

---

✅ 10. RACCOMANDAZIONE PER STEP B #

Procedere con Step B in 4 mini-fasi:

1. B1 (Quick wins ~1.5h): Fast-path + transient cache layer + hook invalidation

→ ROI immediato: endpoint vuoti < 100ms, percezione fluida senza UI changes

1. B2 (Refactor IA ~3h): Menu 7-hub + sub-tab system + History API

→ ROI percepibile: utente vede subito un menu pulito, URLs ordinate

1. B3 (SSR + prefetch ~2h): window.HWInitialData + prefetch on hover

→ ROI alto: first paint istantaneo per overview + sub

1. B4 (Cleanup ~1h): Remove dead code, deprecate legacy endpoints

Totale Step B: ~7.5h, divisibile in 2 sessioni di 3-4h.

Dopo Step B → utente naviga la dashboard FLUIDAMENTE, su URL veri, con cache invisibile. Da lì Step C polish hub-by-hub dove ogni hub guadagna design + feature specifiche.

---

📎 APPENDICE A — Endpoint usati per vista #

(Riferimento per Step B cache configuration)

views-overview.js     → /overview
views-hosting.js      → /hosting, /hosting/{id}/upgrade-options
views-domains.js      → /domains, /domain-limits, /domains/{d}/*, /databases, /ftp, /cron/*
views-wordpress.js    → /wordpress, /wordpress/install-targets, /wordpress/stats, /wordpress/{id}/*
views-email.js        → /email, /email/domains, /email/aliases, /email/info, /email/stats
views-backups.js      → /backups, /backups/*
views-files.js        → /files-list, /files-read, /files-status, /files-* (write/chmod/etc)
views-services.js     → /services, /services/{slug}, /services/sites, /services/{}/checkout
views-service-orders  → /service-orders, /service-orders/{id}, /quotes/{id}
views-my-quotes.js    → /my-quotes
views-tickets.js      → /tickets, /tickets/services, /tickets/{id}
views-misc.js         → /account, /billing/invoices, /billing/payment-methods, /orders, /countries, /addons

V2 billing dashboard  → /hostwebo-billing/v1/subscriptions/me, /invoices/me, /users/me/*
V2 affiliate          → /hostwebo-billing/v1/affiliate/* (cliente-side)
V2 welcome            → /hostwebo-billing/v1/welcome/*

---

📎 APPENDICE B — Linee di codice da modificare in Step B #

Stima conservativa:

• dashboard.js (553 righe): +200 righe (menu refactor + sub-tabs + History API)
• core.js (337 righe): +100 righe (cache utility client-side)
• Nuovo file includes/cache/class-dashboard-cache.php: ~200 righe
• Nuovo file includes/dashboard/class-ssr-bootstrap.php: ~150 righe
• Modifiche a ~10 controller REST: +20 righe ognuno (fast-path) = ~200 righe
• page-dashboard.php template: +30 righe (SSR inject)
• Rimozioni: views-credit.js (196), eventualmente checkout.js (904)

Totale impatto: +900 righe code, -1100 righe legacy = NET -200 righe più chiare e veloci.