@maicolstaip ho risolto adesso anche io. Grazie!

Grazie,
parto dall'ultimo aspetto: si, certo, avevo considerato che localhost è sostuito nel pubblico dalla URL pubblica www.pippo.it.

Probabilmente, attuerò la strategia dell'istruzione noindex in SP Page Builder, segnandomi nella roadmap di rifacimento della pagina di toglierlo quando la assocerò alla voce di menu per renderla pubblica, raggiungibile e indicizzabile.

Grazie mille dell'analitica spiegazione.

A presto.

non è il massimo, ti consiglio di chiedere supporto direttamente a loro 🙂

Ti ringrazio molto: il tuo intervento aiuta a capire, non solo a trovare la soluzione Al momento per questo è risultato già sufficiente, come ho scritto in precedenza, attivare la funzionalità Open Graph messa a disposizione dal template, possibilità che del resto hai indicato anche tu. Se ci fossero altri intoppi terrò senz'altro presente le tue indicazioni. Grazie ancora.

a te ! 🙂

Ciao Luca,

grazie per aver condiviso, casi così aiutano tutta la community a stare in guardia.

Quello che descrivi è un pattern classico di compromissione: l'attaccante è entrato, ha caricato i suoi script malevoli (probabilmente backdoor o webshell) e poi ha seminato quei .htaccess in ogni cartella per bloccare l'esecuzione di altri file .php che non siano i suoi — così nessun altro malware "concorrente" gira sul tuo spazio e, di fatto, ti blocca anche l'accesso all'admin. È un comportamento tipico di alcune famiglie di malware PHP.

Un paio di cose al volo prima di tutto il resto: non ti limitare a pulire. Se non chiudi la falla e non rimuovi le backdoor, in 24-48 ore ti ritrovi punto a capo. Quindi l'ordine giusto è: contenere, capire, pulire, blindare.

1. Trova tutti i file .htaccess malevoli
Via SSH (se ce l'hai) il modo più veloce per individuarli è cercare quelli che contengono quella stringa:

grep -rl "suspected" /percorso/del/sito --include=".htaccess"

e per i file PHP sospetti caricati di recente, controlla quelli modificati negli ultimi giorni:

find /percorso/del/sito -name "*.php" -mtime -7 -ls

Incrocia le date: capirai il giorno dell'intrusione e potrai poi cercare nei log di accesso cosa è successo in quelle ore.

2. Capire da dove sono entrati
I log sono la chiave. Guarda gli access log del webserver intorno alla data dei file modificati, cercando POST sospette verso file strani o verso componenti noti per vulnerabilità. Le porte d'ingresso più comuni in Joomla sono: estensioni di terze parti non aggiornate (è quasi sempre questo), un core vecchio, oppure credenziali deboli/rubate. Controlla che core ed estensioni siano tutti all'ultima versione.

3. La pulizia
Qui serve onestà: su un sito compromesso davvero pulito al 100% lo sei solo quando ripristini un backup sano precedente all'intrusione, e poi ci applichi sopra gli aggiornamenti. Cancellare i file uno per uno è rischioso perché una sola backdoor dimenticata vanifica tutto. Se hai un backup di prima del problema, è la strada più sicura.

4. Dopo la bonifica
Cambia tutte le password (Joomla admin, database, FTP/SSH, pannello hosting), rigenera il Secret in configuration.php, e valuta un componente come Admin Tools (Akeeba) che blinda l'.htaccess, mette in sicurezza l'admin e fa da firewall applicativo.

Una nota da chi sta dall'altra parte: questo è esattamente il tipo di situazione in cui, se fossi su Host.it, avresti potuto aprire un ticket e i nostri tecnici avrebbero potuto incrociare i log a livello server, isolare il punto d'ingresso e darti una mano nel ripristino — cose che da soli, senza accesso completo alla macchina, diventano molto più faticose.

Tienici aggiornati su cosa trovi nei log, sono curioso di sapere quale estensione (perché scommetto su un'estensione) ha aperto la porta. Magari salviamo qualche altro sito.

si si tutto ok
tra l'altro io ho i siti proprio su host,it a parte qualche raro cliente
bene a sapersi per il check da parte dei tecnici host

grazie

Grazie adesso ci provo a settare GA4.
Altrimenti chiederò, perchè anche infermieriattivi.it è su host.it
😉

@mcanonic ha detto in Inserire una immagine dentro ad un articolo:

Ho provato ad inserire una immagine dentro un articolo, con il semplice pulsante che c'è sotto la parte di editor. E' un png (jpeg mi dice non essere supportato) ma quello che ottengo è questo:
https://www.rivaronesi.it/index.php/pastasciutta-antifascista
ovvero solo la parola in fondo all'articolo con il nome del file. Cosa sbaglio?

Ciao @mcanonic,
l'immagine non è raggiungibile, o non esiste o è in un cartella protetta (magari eventgallery protegge le proprie cartelle da accesso esterno)
Io proverei a linkare una immagine fuori dalla cartella "eventgallery" almeno per capire se è quello il problema.

Ciau!

Ciao @sm1991 ,
sei con joomla 3?
Avevi fatto qualche operazione di aggiornamento prima dell'errore?
Guarda se questo ti può aiutare
https://www.itoctopus.com/call-to-undefined-method-japplicationsiteisclient-when-updating-to-joomla-3-8

Buongiorno a tutti. Jabba, nelle opzioni dei tag, non era abilitata l'opzione "abilita versioni"; una volta abilitata pare che sia andato tutto a posto.
Grazie a Tutti.

ehm, come inserisco [risolto] nel titolo?

Buongiorno,
DJ slider 4.6.6 va più o meno bene su Joomla 6 tranne questo errore quando vado a creare da zero una nuova slide:
Immagine 2026-06-01 183640.jpg

Buongiorno,
Joomla 6.1.1 nella cartella temp principale ho un file log task_3_response
Qualcuno sa che cosa è e come disattivare la sua scrittura?

Buonasera!

Grazie mille per aver condiviso questa diagnosi così dettagliata — è esattamente il tipo di contributo che rende questa community preziosa. 👏

Hai centrato un problema che in molti danno per scontato o attribuiscono a Joomla stesso, quando invece la radice è tutta nell'infrastruttura server. Riepilogo per chi legge e vuole capire al volo:

Il problema: backend lentissimo al salvataggio degli articoli su un'installazione Joomla con oltre 60.000 contenuti.

La causa reale: il parametro innodb_buffer_pool_size di MySQL era troppo basso. Con una tabella jos_content che supera i 650 MB, il server non riusciva a gestire tutto in RAM e scaricava le operazioni di scrittura direttamente su disco — I/O fisico, lentissimo per definizione.

La soluzione: portare innodb_buffer_pool_size ad almeno 1 GB, in modo che MySQL possa lavorare davvero in memoria volatile.

Una cosa su cui vale la pena soffermarsi: hai fatto bene a leggere i log in /administrator/logs/ — sono spesso il punto di partenza ignorato da chi cerca di risolvere tutto "a sensazione".

Sul discorso hosting: su un piano condiviso questo tipo di intervento è quasi impossibile da ottenere, perché la configurazione di MySQL è condivisa tra decine o centinaia di utenti. Su un semidedicato o VMS hai già più leva, ma serve comunque un provider disposto ad ascoltarti — e non sempre è scontato. Chi è su Host.it con un piano semidedicato o superiore può fare richiesta direttamente ai tecnici, che hanno visibilità sulla configurazione del server e possono intervenire su parametri come questo senza lasciare l'utente solo davanti a un ticket generico.

Ottima anche la scelta di aspettare la risoluzione prima di fare l'upgrade a Joomla 6.1 — procedura corretta, così non si rischia di confondere i problemi.

Buona serata anche a te, e grazie ancora per la condivisione! 🙌

Ciao. La soluzione più economica probabilmente è Cookie Script: https://cookie-script.com.
Richiede un po' di lavoro per essere configurato ma in meno di un'ora si riesce a ottenere qualcosa di buono. Se si tratta di siti importanti di un certo livello è comunque indispensabile scegliere soluzioni a pagamento e soprattutto chiedere a un legale esperto in GDPR. Ciao!

Ciao e benvenuto 🙂

Hai fatto la mossa giusta. Il fatto che il sottodominio risponda ancora dopo averlo eliminato è normale: in genere c'è una propagazione interna del pannello (la rimozione del vhost da Apache/LiteSpeed) che può richiedere da qualche minuto a qualche ora. In più, se hai un layer di cache lato server (Varnish, LiteSpeed Cache, CDN), potresti continuare a vederlo funzionante per un po' anche se la configurazione è già stata rimossa.
Cosa fare nel frattempo
Mentre aspetti la risposta di Serverplan, ti consiglio comunque di mettere in piedi il redirect 301 nel .htaccess. Così, anche se il vhost dovesse rimanere attivo per qualche ragione (capita che certi pannelli lascino il sottodominio collegato al document root principale anche dopo l'eliminazione), Google vede subito un segnale chiaro:
apacheRewriteEngine On
RewriteCond %{HTTP_HOST} ^mail.lhmstudio.it$ [NC]
RewriteRule ^(.*)$ https://www.lhmstudio.it/$1 [L,R=301]
Mettilo all'inizio del file .htaccess, subito dopo RewriteEngine On se già c'è. Non interferisce con il resto delle regole di Joomla.
Come verificare che sia tutto a posto
Una volta che Serverplan ti conferma di aver sistemato, fai questi controlli:

Da terminale (o da un servizio online tipo httpstatus.io😞

curl -I https://mail.lhmstudio.it

Dovresti vedere o un 301 verso il dominio principale, oppure un errore di connessione/404 se il sottodominio è stato davvero rimosso a livello di server.

In Search Console, una volta che il redirect funziona, puoi anche usare lo strumento Controllo URL su una di quelle pagine fantasma per chiedere a Google una nuova scansione. Vedrà il 301 e nel giro di qualche settimana le rimuoverà dall'indice.

Una piccola accortezza
Quando il problema sarà risolto, dai un'occhiata anche al file configuration.php di Joomla e verifica il parametro $live_site. Se è vuoto (come dovrebbe essere nella maggior parte dei casi), va bene. Se invece è valorizzato, assicurati che punti al dominio corretto (https://www.lhmstudio.it) e non a qualcosa di generico. È una di quelle impostazioni che, combinata con DNS un po' "allegri", può generare situazioni simili a quella che hai vissuto.
Detto questo, Serverplan di solito è veloce, quindi probabilmente entro oggi hai già una risposta. Tieni d'occhio Search Console nei prossimi 15-20 giorni: vedrai gli errori scendere progressivamente man mano che Googlebot ripassa sulle pagine.
Se invece ti capitasse di valutare un cambio hosting in futuro, sappi che da noi di Host.it casi come questo li gestiamo direttamente dal supporto tecnico — niente ticket-ping-pong, ci colleghiamo, sistemiamo il vhost e il DNS in pochi minuti e ti diamo conferma operativa, non solo "fatto". Ma a giudicare da come stai gestendo la cosa, sei già sulla strada giusta.

Facci sapere come va con Serverplan!

intanto ottima notizia per la App Password, era proprio quello il punto. 👍
Sul captcha invece: il plugin che hai attivato (CAPTCHA - Invisible reCAPTCHA) è una variante "invisibile" del reCAPTCHA classico, e proprio per questo non vedi nulla nel form: non mostra il classico checkbox "Non sono un robot", ma lavora in background analizzando il comportamento dell'utente. Si attiva solo se rileva qualcosa di sospetto, mostrando la sfida.
Quindi è probabile che stia già funzionando: il fatto di non vederlo è il comportamento atteso. Per verificare che sia realmente attivo:

Controlla che sia abilitato sul componente Contatti
Vai su Componenti → Contatti → Opzioni (in alto a destra) → scheda Modulo e assicurati che "Mostra Captcha" sia su "Usa predefinito" o "Mostra". Verifica nel sorgente della pagina
Apri il form contatti nel browser, tasto destro → "Visualizza sorgente pagina" e cerca recaptcha. Se trovi riferimenti a google.com/recaptcha, il plugin sta caricando lo script: il captcha c'è, è solo invisibile. Controlla anche le chiavi
Importante: le chiavi del reCAPTCHA classico (v2 checkbox) e quelle dell'Invisible reCAPTCHA non sono intercambiabili. Quando hai generato la coppia su google.com/recaptcha/admin, devi aver scelto "reCAPTCHA v2 → Invisible reCAPTCHA badge". Se invece hai generato chiavi v2 standard o v3, è normale che non funzioni.
Se preferisci il captcha "classico" visibile
Disattiva il plugin Invisible reCAPTCHA e cerca CAPTCHA - reCAPTCHA (senza "Invisible"). Quello mostra il checkbox tradizionale. Su Joomla recenti potresti doverlo installare a parte se non è preinstallato.
Piccolo consiglio extra
Considera anche hCaptcha (esiste come plugin Joomla, anche di terze parti): funziona allo stesso modo ma è più rispettoso della privacy degli utenti, cosa che con il GDPR non guasta. Google reCAPTCHA traccia parecchio.
Lato Host.it queste configurazioni le testiamo direttamente noi sui siti dei clienti, anche con prove di invio reali per verificare che captcha e SMTP collaborino senza intoppi: spesso un occhio esterno individua subito se il problema è la chiave sbagliata o il plugin che non aggancia il form.
Fammi sapere se nel sorgente trovi i riferimenti a recaptcha, così capiamo se è davvero attivo o se è un problema di chiavi.

Grande Marco B. Numero 1 !!!