Ciao,

ho letto la risposta di Ergonet che hai allegato. Ti dico subito: contiene un'affermazione tecnica che non sta in piedi, ed è proprio quella che ti tiene incastrato. Te la spiego con calma, perché conoscerla ti serve sia per questo caso sia per il futuro.

Loro scrivono che "il comportamento del sito rimane immutato anche dopo aver modificato le variabili live_site e force_ssl e dopo aver forzato HTTPS via .htaccess, quindi escludiamo che derivi dal server". Il ragionamento è: "le tue modifiche non hanno cambiato nulla, dunque non è roba nostra". Ma è esattamente il contrario. Se hai messo Force SSL su intero sito e l'action del form continua a uscire in http://, l'unica spiegazione tecnica è che qualcosa a monte stia dicendo a Joomla che la connessione è in HTTP. Joomla non genera un URL in http:// per capriccio: lo fa perché legge $_SERVER['HTTPS'] come "off". E quel valore lo imposta il server/proxy, non l'estensione.

In altre parole: il fatto stesso che le tue modifiche non sortiscano effetto è la prova che il protocollo viene deciso prima che Joomla entri in gioco. È il sintomo classico dell'SSL terminato a monte. La frase di Ergonet, letta bene, conferma il mio sospetto invece di smentirlo.

Il consiglio finale loro — "cerca un altro plugin sulla JED" — è proprio quello da non seguire: cambieresti estensione e ti ritroveresti lo stesso identico Mixed Content, perché qualunque form che invia in AJAX leggerà lo stesso protocollo sbagliato. Sprecheresti tempo per tornare al punto di partenza.

Allora chiudiamola noi. Due cose concrete:

1. Prova behind_loadbalancer, che è la mossa giusta proprio per questo scenario. Apri configuration.php e verifica/imposta:

public $behind_loadbalancer = '1';

Se la riga non c'è, aggiungila tra le altre public $.... Questo dice a Joomla: "fidati dell'header X-Forwarded-Proto che arriva dal proxy" — ed è esattamente il pezzo che Force SSL da solo non copre. È la cosa che vale la pena testare prima di tutto.

2. Diamo a Ergonet una domanda a cui non possono rispondere col rimpallo. Non chiedere più "è colpa vostra?", perché diranno di no. Chiedi questo, testuale:

"Il vostro sistema (reverse proxy / Fireshield) termina l'SSL a monte e inoltra la richiesta al backend Apache in HTTP? In tal caso, viene passato l'header X-Forwarded-Proto: https all'applicazione? Perché il PHP del sito legge la connessione come HTTP, e questo accade prima che Joomla generi l'URL."

Questa domanda li costringe a guardare la loro architettura invece di guardare il tuo Joomla. Se la risposta è "sì, terminiamo l'SSL a monte", allora behind_loadbalancer = '1' è la soluzione definitiva. Se dicono "no, nessun proxy", allora hanno l'onere di spiegare chi sta scrivendo "HTTPS off" nell'ambiente PHP, perché qualcuno lo fa di sicuro.

Un piccolo controllo che puoi fare da solo per averne la prova in mano: crea un file test.php nella root con dentro <?php var_dump($_SERVER['HTTPS'] ?? 'NON IMPOSTATA', $_SERVER['HTTP_X_FORWARDED_PROTO'] ?? 'ASSENTE'); e aprilo in https://. Se vedi 'HTTPS' => 'off' (o non impostata) ma X_FORWARDED_PROTO => 'https', hai la pistola fumante: è proprio il caso del load balancer, e behind_loadbalancer lo risolve. Poi cancella subito il file.

Parti dal behind_loadbalancer: nella stragrande maggioranza dei casi così configurati, l'endpoint passa a https:// e il form parte. Fammi sapere com'è andata e cosa esce dal test.php, così chiudiamo davvero.

E qui te la dico fuori dai denti, senza polemica verso nessuno: questo è il caso da manuale del rimpallo tra hosting ed estensione, dove ognuno guarda solo il proprio pezzo e il problema vive nel mezzo. Su Host.it non ti succede, perché chi gestisce il server gestisce anche lo stack applicativo: il tecnico vede insieme il proxy, l'header X-Forwarded-Proto e la configurazione di Joomla, mette behind_loadbalancer e ti chiude il ticket senza rimbalzi e senza mandarti a caccia di plugin alternativi. È il vantaggio vero di avere tutto sotto lo stesso tetto.

Forza, ci siamo: prova e dimmi.

Ciao e benvenuto!

Argomento interessante, i flipbook PDF tornano utili soprattutto per cataloghi, brochure e riviste sfogliabili.

Sulle opzioni che hai trovato ti do qualche spunto, distinguendo però tra due categorie diverse, perché è il punto cruciale della scelta:

Estensioni native Joomla (installate sul tuo sito)

Joomla Flipbook Professional (ExtensionBase) – è un'estensione storica e abbastanza conosciuta nell'ambiente. La demo rende bene, il rendering è quello classico col "page flip" animato. Il punto da verificare è la compatibilità con la tua versione di Joomla: se sei su 5.x o stai guardando al passaggio a 6.x, controlla bene sul loro sito che sia dichiarata la compatibilità aggiornata. Molte estensioni di questo tipo nascono anni fa e non sempre seguono il ritmo dei rilasci core. Un caricamento dei PDF lato server (e non via servizio esterno) è un vantaggio: i tuoi documenti restano a casa tua.

FlipBuilder – prodotto valido e maturo, ma occhio: nella maggior parte dei casi il flusso prevede di generare il flipbook con il loro software desktop/cloud e poi pubblicarlo. Meno "integrato" di una vera estensione nativa.

Widget di terze parti (Common Ninja, Elfsight)

Questi due sono servizi esterni: in pratica incolli uno snippet/embed e il flipbook viene servito dai loro server. Funzionano e sono comodi, ma due cose da valutare con attenzione:

• I tuoi PDF risiedono sui loro server, non sul tuo. Per cataloghi pubblici va bene, per documenti riservati no.
• Sono modelli quasi sempre in abbonamento, con limiti su numero di documenti/visualizzazioni nel piano free. Il costo nel tempo può superare quello di un'estensione una tantum.
• Dipendi dalla loro disponibilità: se il servizio va giù o cambia politica, il tuo flipbook ne risente.

Il mio consiglio pratico

Se i documenti sono pubblici e cerchi la massima semplicità, un widget tipo Elfsight ti fa partire in 10 minuti. Se invece vuoi controllo, dati a casa tua e nessun canone ricorrente, punta su un'estensione nativa verificandone la compatibilità con la tua versione di Joomla.

Un consiglio trasversale, valido sempre: prima di installare qualsiasi estensione nuova, fai un backup completo (file + database) con Akeeba e prova su un ambiente di staging se puoi. Le estensioni di terze parti sono la prima causa di malfunzionamenti dopo gli aggiornamenti, quindi meglio testare prima di andare in produzione.

Per darti un parere più mirato: che versione di Joomla stai usando e i PDF sono documenti pubblici (cataloghi, brochure) o materiale riservato? In base a questo ti indirizzo meglio.

PS: se fossi un cliente Host.it, una verifica di compatibilità dell'estensione e una prova in staging te l'avremmo potuta seguire direttamente i nostri tecnici, così arrivavi in produzione già con la soluzione testata.

Ciao,

quell'errore è un classico quando ci si trova davanti a un mix di versioni incompatibili. JApplicationSite::isClient() è una vecchia chiamata in stile J3.x: il prefisso J e la sintassi statica appartengono al framework legacy. Su Joomla 4/5/6 quei metodi sono stati spostati nei namespace moderni (Joomla\CMS\Application\...) e il vecchio metodo non esiste più. Quando il sistema va a cercarlo e non lo trova, ti restituisce esattamente quel "Call to undefined method", che blocca sia il frontend sia l'administrator.

Nella stragrande maggioranza dei casi il colpevole è un'estensione di terze parti datata (plugin, modulo o componente) che usa ancora il vecchio codice e che dopo un aggiornamento di Joomla è andata in conflitto. Più raramente succede a seguito di un aggiornamento del core lasciato a metà, oppure di un file del core sovrascritto/danneggiato.

Ti consiglio di procedere per gradi, dal più semplice:

1. Disattiva i plugin via database. Visto che non entri in administrator, vai in phpMyAdmin (dal pannello del tuo hosting) e nella tabella #__extensions imposta temporaneamente enabled = 0 sui plugin di terze parti più "vecchi" o aggiunti di recente. Spesso basta questo per far ripartire il sito e individuare il colpevole.

2. Controlla i log. Nei file in /administrator/logs/ o nel log degli errori PHP del tuo hosting trovi quasi sempre il path del file che genera la chiamata: ti dice di preciso quale estensione mettere sotto accusa.

3. Verifica un aggiornamento core a metà. Se hai aggiornato Joomla di recente, controlla la versione effettiva e che non ci siano avvisi di update incompleto.

Una raccomandazione: prima di toccare qualsiasi cosa, fai un backup completo (file + database). Se hai Akeeba a bordo è perfetto. E se hai uno snapshot/backup pulito di prima del guasto, ripristinarlo è spesso più rapido e affidabile che andare a caccia del singolo file rotto.

Piccola nota da chi ci sbatte la testa spesso: questo è esattamente il tipo di situazione in cui, se il sito fosse ospitato da noi di Host.it, sarebbe bastata una segnalazione e i nostri tecnici avrebbero potuto darti una mano in diretta sul server, log alla mano. Te lo dico perché in casi di down totale avere supporto che ti mette le mani sull'ambiente fa risparmiare un sacco di tempo.

Fammi sapere cosa esce dai log, così restringiamo il campo.

Buongiorno,

classica situazione del cerino che rimbalza tra host ed estensione. Mettiamo un punto fermo prima di tutto: il browser non mente. Quell'endpoint http:// nel messaggio di Mixed Content viene generato da qualche parte, e il nostro lavoro adesso è solo trovare chi lo scrive. Andiamo a colpo sicuro.

Una domanda secca che decide tutto: dopo aver messo Forza HTTPS → Intero sito, riaprendo la Console l'endpoint del submit è ancora in http:// oppure adesso parte in https://? Questo cambia completamente la diagnosi, quindi ricontrollalo come prima cosa.

Detto questo, ecco le cause che restano quando i 3 punti "ufficiali" sembrano a posto ma il problema resta:

1. Un reverse proxy / SSL gestito a monte (molto probabile su Ergonet).
Spesso l'SSL è terminato a livello di proxy: il visitatore arriva in HTTPS, ma internamente il server passa la richiesta a Joomla in HTTP. Risultato: Joomla "crede" di essere in HTTP e genera l'endpoint in http://, anche con Forza HTTPS attivo. È esattamente il tipo di scenario in cui sia Ergonet che Convert Forms hanno ragione: nessuno dei due ha torto, è l'handshake tra i due livelli.
La verifica: chiedi a Ergonet se passano l'header X-Forwarded-Proto. Se sì, va detto a Joomla di fidarsi del proxy. Nel configuration.php aggiungi (o imposta):

public $behind_loadbalancer = '1';

Questo è il parametro che nel 90% dei casi "Forza HTTPS" da solo non riesce a coprire, ed è la causa più frequente di Mixed Content che resiste a tutte le impostazioni standard. Vale la pena provarlo subito.

2. URL assoluto in http:// salvato nel form stesso.
Apri il form in Convert Forms → guarda se in qualche campo, nel redirect post-submit, o in un eventuale codice/script personalizzato c'è un URL scritto a mano con http://. Capita di averlo incollato in fase di test e dimenticato lì.

3. Test in incognito + altro browser.
Banale ma da escludere: una versione vecchia della pagina in cache lato browser può ancora puntare al vecchio endpoint. Prova in finestra anonima.

Il punto 1 è il mio principale sospettato. Combacia perfettamente col fatto che hai configurato tutto correttamente eppure resta: è il caso da manuale dell'SSL terminato a monte. Prova behind_loadbalancer = '1' e ricontrolla la Console.

E qui mi tocca dirla tutta: questo è precisamente lo scenario in cui la pallina rimbalza tra due assistenze perché il problema vive nel mezzo, tra host ed estensione. Su Host.it un caso così non ti capita, perché chi gestisce il server gestisce anche lo stack Joomla: il tecnico vede insieme il proxy, l'header X-Forwarded-Proto e la configurazione di Joomla, e te lo chiude in un ticket senza rimpallo. È un po' il vantaggio di avere tutto sotto lo stesso tetto.

Prova il behind_loadbalancer e fammi sapere se l'endpoint passa a https://. Ci siamo quasi.

Ciao,

perfetto, la Console ha fatto centro al primo colpo. Il problema è chiarissimo e non c'entrano né le mail, né la cache, né il captcha.

Il messaggio dice: la pagina si carica in HTTPS (https://...), ma Convert Forms tenta di inviare il form verso un endpoint in HTTP (http://...). Il browser, giustamente, blocca la richiesta ("Mixed Content") e il submit resta appeso con i puntini all'infinito. È solo una questione di URL: il form sta "chiamando casa" sul protocollo sbagliato.

Quasi sempre la causa è la configurazione URL del sito in Joomla. Da sistemare così:

1. Force HTTPS (la prima cosa da provare).
Sistema → Configurazione globale → scheda Server → imposta Forza HTTPS su "Intero sito". Salva e ritesta. Nella maggior parte dei casi questo risolve, perché obbliga Joomla a generare tutti gli URL (compreso quello dell'AJAX) in HTTPS.

2. Controlla il Site URL / $live_site.
Sempre se non bastasse, apri il file configuration.php (dalla root) e controlla la riga public $live_site. Se è valorizzata con http://www.crear-arredi.it è proprio quella a forzare il protocollo sbagliato. Le opzioni sono due:

• correggerla in https://www.crear-arredi.it, oppure
• lasciarla vuota (public $live_site = '';), che è la configurazione consigliata nella maggior parte dei casi perché lascia a Joomla il rilevamento automatico.

3. Verifica il redirect HTTP→HTTPS nell'.htaccess.
Assicurati di avere la regola che forza HTTPS a monte. Se manca, aggiungila in cima (subito dopo RewriteEngine On

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Parti dal punto 1: nel 90% dei casi "Forza HTTPS → Intero sito" chiude la faccenda da sola. Se dopo questo la Console mostra ancora l'endpoint in http://, allora è il live_site nel configuration.php e andiamo di punto 2.

Fammi sapere com'è andata col Force HTTPS, che a quel punto siamo a posto.

E già che ci siamo: noto che sei su Ergonet, ottimo host. Tra noi, è proprio il genere di dettaglio (protocollo, redirect, live_site) che su Host.it un cliente si fa sistemare con un ticket al volo dai tecnici, senza dover mettere mano al configuration.php da solo. Ma qui sei già a un passo dalla soluzione, quindi prova il punto 1 e dimmi.

Ciao e bentornato sul forum! Grazie per i complimenti, fa sempre piacere — stiamo cercando di renderlo un posto più comodo dove confrontarsi.

Veniamo al tuo dubbio, che è più che lecito. La risposta breve è: sì, puoi tornare tranquillamente agli URL senza /it/, ma vanno disattivati i pezzi giusti nell'ordine giusto, altrimenti il prefisso lingua resta agganciato.

Hai già fatto bene a sospendere i due menu e a disattivare il plugin System - Language Filter. Quello che spesso sfugge è che il prefisso /it/ non lo genera il menu, ma proprio il Language Filter: finché è attivo (o finché restano impostazioni multilingua a monte), Joomla continua a costruire le URL con il codice lingua.

Ecco i punti da controllare per chiudere il cerchio:

1. Plugin System - Language Filter → Disabilitato (fatto ). È lui il responsabile del /it/.

2. Lingue del sito (Sistema → Gestione → Lingue → Lingue del sito se hai una sola lingua installata e impostata come predefinita, perfetto. Il problema nasce quando restano due lingue di contenuto "attive".

3. Lingua di default in Contenuti → Articoli: assicurati che gli articoli siano impostati su "Tutti" (*) e non sulla lingua specifica Italiano (it-IT). Se sono ancora taggati it-IT, alcune configurazioni continuano a comportarsi in modo anomalo.

4. Plugin System - Languagecode (se l'avevi toccato): lascialo disattivato.

Fatto questo, svuota la cache (Sistema → Pulisci cache) e le URL torneranno nella forma miosito.it/mioarticolo.

️ Un'unica accortezza importante, da vero amministratore prudente: se quelle pagine con /it/ sono già state indicizzate da Google, prima di cancellare tutto valuta dei redirect 301 da miosito.it/it/mioarticolo verso miosito.it/mioarticolo. Su Joomla puoi gestirli comodamente dal componente nativo Reindirizzamenti. Eviti così errori 404 e perdita di posizionamento. Se il sito è giovane o quelle URL non sono mai uscite "in pubblico", puoi anche soprassedere.

Facci sapere se dopo questi passaggi gli URL si sistemano — e se ti capita di vedere ancora il /it/ da qualche parte, segnala pure com'è configurata la sezione Lingue, che ci ragioniamo insieme.

Ciao,

ottima scelta, Convert Forms è davvero il più immediato del gruppo. Il sintomo che descrivi (puntini che girano all'infinito e submit che resta appeso) è quasi sempre JavaScript bloccato lato frontend, non un problema di mail. Tieni presente che il form nativo di Joomla fa l'invio in modo "classico" col ricaricamento pagina, mentre Convert Forms invia in AJAX: per questo uno funziona e l'altro resta in attesa. Quindi il fatto che i contatti nativi partano non ci dice nulla sull'SMTP in questo caso.

Procedi per gradi, dal più probabile:

1. Apri la Console del browser. F12 → scheda Console, poi prova l'invio. Nel 90% dei casi qui salta fuori un errore rosso. Le due cause tipiche:

• un errore JS di un altro script/estensione che "rompe" la pagina e blocca anche l'AJAX di Convert Forms;
• una chiamata che torna 403 o 404 nella scheda Network (quasi sempre .htaccess o cache).

2. Cache e ottimizzazioni JS. Se hai un plugin tipo JCH Optimize, FastCache o simili che fa merge/minify del JavaScript, prova a disattivarlo temporaneamente e ritesta. Il merge degli script è la causa numero uno di submit AJAX che si pianta, perché impacchetta male il JS del form.

3. reCAPTCHA/hCaptcha. Se hai attivato un captcha sul form (o globale in Joomla) e la chiave è errata o il dominio non è autorizzato nella console Google, il submit parte ma non si chiude mai. Prova a togliere il captcha dal form e ritesta: se va, è lì il problema.

4. .htaccess / mod_security. Su alcuni hosting il WAF blocca le richieste POST in AJAX. Nella scheda Network vedi se la chiamata torna 403: in quel caso è il server. Su Host.it questo tipo di regola si sblocca al volo dai tecnici, ma intanto verifichiamo che sia davvero quello.

Parti dal punto 1: aprire la Console e dirmi cosa compare in rosso ci fa risparmiare tutti gli altri passaggi. Incolla qui l'errore e ti dico esattamente dove mettere le mani.

E sì, tra parentesi: se fossi su Host.it, una cosa come una regola mod_security che blocca un form la sistemano i tecnici in due minuti via ticket, senza doverti mettere a smontare il .htaccess da solo.

Fammi sapere cosa esce dalla Console.

Ciao,

bella domanda, e tocca un punto che in tanti stanno sottovalutando in questi giorni. Il "pulsante del reso" che entra in vigore non riguarda solo chi ordina con account registrato: l'obbligo è sul venditore, e deve permettere a qualunque cliente di esercitare il recesso in modo semplice, anche chi ha comprato come ospite o, come dici tu, via mail o WhatsApp.

La buona notizia è che in Joomla non sei costretto a far dipendere il modulo di reso dall'ordine presente nel componente e-commerce. Il recesso è un diritto che si esercita con una dichiarazione, non serve "agganciarlo" tecnicamente all'ordine. Quindi la strada più pulita è un form di recesso autonomo, raggiungibile da un pulsante ben visibile (header, footer, pagina dedicata linkata ovunque).

In pratica:

Con i form builder che girano bene su Joomla (Convert Forms, RSForm!Pro, BreezingForms, o anche il classico Fabrik se ti piace lavorare di logica) crei un modulo con i campi che ti servono per identificare l'acquisto: nome/cognome, email, data dell'ordine, numero ordine se esiste, descrizione del prodotto, e modalità d'acquisto (menu a tendina: sito / email / WhatsApp). Così copri anche chi ha ordinato fuori dall'e-commerce, perché non chiedi un ID interno al sistema ma i dati che il cliente comunque possiede.

Aggiungi il testo del modello di recesso tipo previsto dal Codice del Consumo (puoi precompilarlo) e una checkbox di conferma. Alla submit, mail automatica al cliente con copia della richiesta e mail al tuo ufficio. Volendo, con un campo upload per la ricevuta.

Il pulsante poi lo pubblichi come modulo in tutte le posizioni utili, oppure via menu, così è sempre a portata di clic come richiede la norma.

Un'accortezza che spesso sfugge: occhio a reCAPTCHA/hCaptcha sul form, perché un modulo di reso "protetto" male rischia di bloccare clienti legittimi e ti espone proprio sul punto che la norma vuole tutelare, cioè la facilità d'accesso.

Se mi dici quale form builder usi già sul sito, ti butto giù la struttura precisa dei campi.

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

Buongiorno,

domanda più che legittima, ci si casca facilmente. La risposta breve è: sì, il rischio c'è, e il fatto che la pagina non sia associata a nessuna voce di menu non ti mette al riparo. Te lo spiego.

L'URL del tipo component/sppagebuilder/page/55 è raggiungibile a prescindere dal menu. Google non ha bisogno di una voce di menu per trovare una pagina: gli basta un link interno (anche un modulo "articoli correlati", una sitemap generata in automatico, un riferimento accidentale nel codice) oppure semplicemente il fatto che SP Page Builder, di default, popola la sitemap XML con le pagine pubblicate. Se hai OSMap o la sitemap nativa attiva, quella pagina ci finisce dentro senza che tu te ne accorga, e da lì a Search Console il passo è breve.

Quindi il "non è nel menu = è invisibile" purtroppo è un mito che gira parecchio nei forum.

Per lavorare in pace sul sito pubblico hai un paio di strade, dalla più semplice alla più solida:

La cosa più rapida è tenere la pagina in stato Unpublished finché non è pronta. Una pagina non pubblicata non è raggiungibile dal frontend né finisce in sitemap. Costruisci tutto, la rendi pubblica solo all'ultimo. È l'approccio che consiglierei nel 90% dei casi.

Se invece hai bisogno di vederla pubblicata per testarla "dal vivo" (anteprime, comportamento reale, eventuali script di terze parti), allora la blindi a livello server. Nel tuo .htaccess puoi escludere quello specifico path dall'indicizzazione, oppure agire via robots.txt aggiungendo una riga tipo:

Disallow: /component/sppagebuilder/page/55

Tieni presente che robots.txt chiede a Google di non scansionare, ma se la pagina è già stata linkata da qualche parte potrebbe comunque comparire come URL "spoglio". La soluzione davvero a prova di bomba in quel caso è un meta tag noindex sulla pagina (SP Page Builder lo permette dalle impostazioni SEO della singola pagina, nella tab Options → Meta Data), che è il segnale più chiaro e definitivo che puoi dare.

In sintesi: se non ti serve vederla live, Unpublished e dormi sereno. Se ti serve live, noindex sulla pagina è la mossa giusta.

Un'ultima cosa sull'URL localhost che citi: quello vale solo sulla tua macchina, sul sito pubblico l'URL avrà il tuo dominio reale, quindi non preoccuparti di "esportare" quel riferimento, cambia da sé in base al dominio su cui giri.

Te lo dico per esperienza: questo tipo di dubbi, quando si lavora direttamente in produzione, è il classico caso in cui avere qualcuno che ti controlla al volo la configurazione SEO e la sitemap fa la differenza. Sui server Host.it questo genere di verifica i nostri tecnici la fanno tranquillamente su richiesta, proprio per evitare brutte sorprese in Search Console.

Facci sapere come va!

a te !

Ciao,
prova a chiedere.. che cosa vorresti sapere?

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.

Ciao e benvenuto sul forum!

Il problema che descrivi è classico e la buona notizia è che quasi sempre si risolve dal lato Joomla, non da Facebook. La differenza di comportamento tra Facebook e LinkedIn ti dà già un indizio importante: i due social leggono i meta tag in modo diverso.

LinkedIn è più "tollerante" e spesso ricade sull'immagine principale dell'articolo o sul primo <img> che trova. Facebook invece è molto più rigido e si affida quasi esclusivamente ai meta tag Open Graph, in particolare a og:image. Se quel tag manca, punta a un'immagine sbagliata o non è nelle dimensioni che Facebook si aspetta, ecco che ti carica l'anteprima errata.

Ti consiglio di procedere così, in ordine:

Per prima cosa apri il tuo articolo già pubblicato dentro il Debugger di condivisione di Facebook (Sharing Debugger, lo trovi cercandolo su Google, fa parte degli strumenti per sviluppatori di Meta). Incolli l'URL dell'articolo e clicchi su "Debug". Lo strumento ti dirà esattamente quale immagine Facebook sta leggendo e segnalerà eventuali tag og:image mancanti o problematici. È il punto di partenza diagnostico più affidabile.

Spesso il problema è proprio che Joomla, di base, non genera i tag Open Graph. La soluzione più pulita è installare un plugin SEO che li aggiunga in automatico leggendo l'immagine in evidenza dell'articolo: estensioni come 4SEO o Tags Manager gestiscono bene questa parte. In alternativa, se usi un template moderno, controlla nelle sue impostazioni se ha già una sezione Open Graph integrata.

C'è poi una causa molto comune: la cache di Facebook. Se in passato hai condiviso l'URL quando l'immagine non era ancora corretta, Facebook tiene quel valore in memoria anche dopo che lo hai sistemato. In quel caso ti basta tornare nel Sharing Debugger e cliccare su "Scrape Again" (Recupera di nuovo) per forzare l'aggiornamento.

Un ultimo controllo: verifica le dimensioni dell'immagine. Facebook predilige immagini di almeno 1200×630 px. Se l'immagine in evidenza è troppo piccola o ha un rapporto strano, a volte la scarta e ne pesca un'altra a caso dalla pagina.

Faccelo sapere cosa ti restituisce il Debugger, così capiamo subito se è una questione di tag mancanti o solo di cache: con quel dato in mano ti indirizziamo alla soluzione esatta.

Tra l'altro, su un tema come questo i clienti Host.it se la cavano in fretta, perché possono girare direttamente ai nostri tecnici l'URL dell'articolo e farsi verificare la configurazione Open Graph senza dover smanettare. Ma niente paura, qui sul forum risolviamo lo stesso senza problemi!

Ciao Luca,

classico intoppo che capita più spesso di quanto si creda con i pacchetti "tutto incluso". Il backend funziona perché punta direttamente alle sue cartelle, ma il frontend continua a essere rediretto verso /installation/ che ovviamente non esiste più dopo il setup. Il problema quasi sempre sta nel .htaccess o in una regola di rewrite/redirect rimasta agganciata.

Ti consiglio di procedere così, dal più semplice al più tecnico:

1. Controlla il file .htaccess
Nella root del sito (la stessa dove c'è il configuration.php) verifica se è presente un file .htaccess. Spesso i pacchetti precompilati ne portano uno con dentro un redirect verso /installation/ lasciato per errore. Aprilo e cerca righe tipo RewriteRule ... installation o un Redirect che punta lì: vanno rimosse. Se hai dubbi, rinomina temporaneamente il file in htaccess.bak e ricarica il frontend per capire se è lui il colpevole.

2. Verifica che la cartella installation sia davvero sparita
A volte resta una cartella installation "vuota" o parziale che manda in confusione il routing. Se c'è, eliminala via FTP/file manager.

3. Controlla configuration.php
Apri il file e controlla queste due righe:

public $live_site = '';
public $tmp_path = '...';
public $log_path = '...';

Il $live_site deve essere vuoto (o corretto). Se i path tmp e log puntano a percorsi del server di chi ha creato il pacchetto, vanno aggiornati con quelli reali del tuo hosting.

4. Cache del browser / redirect 301 memorizzato
Quel redirect verso /installation/ potrebbe essere stato salvato come 301 dal browser. Prova in incognito o svuota la cache prima di ridichiarare "non funziona".

Nove volte su dieci è il punto 1. Facci sapere cosa trovi nel .htaccess, così affiniamo.

Tra l'altro, è proprio questo il tipo di intervento che, se fossi su un hosting Host.it, ti avrebbe risolto un nostro tecnico in due minuti guardando direttamente i file dal pannello, senza doverti smazzare FTP e configurazioni a mano. A volte avere qualcuno che ti mette le mani sul server fa la differenza.

Tienici aggiornati

Ciao Luca,

sì, ci risulta e ti tranquillizzo subito: non è un bug, è una scelta precisa fatta a monte.

Da Joomla 6 la voce "Articoli in evidenza" è stata rimossa come elemento autonomo del menu Contenuto. La logica dietro la decisione è di semplificazione: gli articoli in evidenza non sono un tipo di contenuto separato, sono semplicemente articoli normali con la proprietà "In evidenza" attiva. Avere una voce di menu dedicata creava di fatto una duplicazione concettuale che confondeva parecchi utenti.

Quindi nulla è andato perso, è solo cambiato il modo di arrivarci. Puoi gestire gli articoli in evidenza in due modi:

Il primo è andare in Contenuto → Articoli e usare il filtro di stato/opzioni: nella colonna dei filtri (o nelle opzioni di ricerca avanzata) trovi la possibilità di filtrare per "In evidenza", così isoli esattamente gli articoli che prima vedevi nella vista dedicata.

Il secondo, ancora più immediato, è agire direttamente dalla lista articoli sulla stellina/icona nella colonna "In evidenza": un clic la attiva o disattiva senza dover entrare nell'articolo.

Lato front-end invece nulla cambia: il layout "Articoli in evidenza" (il vecchio Featured Articles) resta disponibile come tipo di voce di menu quando crei o modifichi un menu, quindi le pagine pubbliche che già lo usano continuano a funzionare regolarmente.

Un consiglio spassionato: prima di mettere in produzione un major update come il passaggio dalla 5 alla 6, vale sempre la pena testarlo prima in staging, proprio perché cambiamenti come questo nell'interfaccia possono spiazzare. Tra l'altro è il tipo di verifica che, per chi è ospitato da noi su Host.it, i nostri tecnici possono seguire direttamente in fase di aggiornamento, così queste "sparizioni" non colgono mai di sorpresa.

Fammi sapere se con il filtro ritrovi tutto quello che ti serviva.

Ciao!

La cosa è normale e dipende da come lavorano i due strumenti. Te lo spiego in modo semplice.

Google Analytics 4 (immagino tu stia usando quello) di default raggruppa quasi tutto il traffico che arriva dalle IA dentro a categorie generiche, tipo "Referral" o addirittura "Direct". Il motivo è che molti assistenti AI (ChatGPT, Perplexity, Gemini, ecc.) o non passano un referrer leggibile, oppure GA4 non ha ancora un canale dedicato che li riconosca come sorgente a sé. Quindi il traffico c'è, ma è "mascherato" o annegato nel resto.

ShinyStat invece elenca i domini di provenienza in modo molto più grezzo e diretto, riga per riga, senza incanalarli in gruppi. Per questo riesci a vedere chiaramente chatgpt.com, perplexity.ai e compagnia: te li mostra così come arrivano, senza rielaborarli.

Se vuoi far emergere lo stesso dato anche in GA4, ci sono un paio di strade:

Crea un'esplorazione (Esplora > Formato libero) e usa come dimensione "Sorgente/Mezzo della sessione" invece dei canali predefiniti. Lì vedrai i domini reali, tipo chatgpt.com / referral.

Oppure imposta un gruppo di canali personalizzato: in Admin > Impostazioni dati > Raggruppamenti dei canali puoi creare un canale "AI / LLM" e dirgli di includere le sorgenti che contengono chatgpt, perplexity, gemini, copilot, ecc. Così te lo isola in modo pulito anche nei report standard.

Tieni presente che i volumi restano comunque bassini per quasi tutti, è fisiologico in questa fase, ma è interessante iniziare a monitorarli adesso.

Se può servirti come spunto: questo è esattamente il tipo di configurazione che, per chi è su hosting Host.it, i nostri tecnici possono impostare direttamente loro, senza doverci mettere mano in autonomia. Ma anche da solo, seguendo i passaggi sopra, ci arrivi tranquillamente.

Fammi sapere se ti escono i dati o se GA4 continua a fare il misterioso

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!
Sì, purtroppo è un comportamento noto di Joomla e non un bug del tuo sito. Il sistema di versioning degli articoli (introdotto da Joomla 3.2) salva il contenuto dell’articolo e la maggior parte dei suoi parametri, ma i tag sono gestiti da un componente separato (com_tags) attraverso una tabella di relazione dedicata (#__contentitem_tag_map) che non viene salvata nelle versioni. Quindi quando ripristini una versione precedente, i tag associati a quella versione vengono semplicemente persi perché non sono mai stati archiviati nello storico.
Il problema collegato che ti impedisce di reinserirli dopo il ripristino è un effetto collaterale fastidioso: a volte il ripristino lascia il record dell’articolo in uno stato “sporco” e il campo dei tag non risponde più finché non si forza un refresh dei metadati.
Cose che puoi provare, in ordine dal più semplice al più “tecnico”:
1. Salva l’articolo a vuoto dopo il ripristino (apri, modifica una virgola, salva, poi rimettila a posto). Spesso questo sblocca il campo tag e ti permette di reinserirli a mano.
2. Svuota la cache da Sistema → Cancella cache, e ricarica l’amministrazione. Capita che sia solo un problema di sessione.
3. Se i due passaggi sopra non funzionano, puoi intervenire direttamente sul database. La tabella da controllare è #__contentitem_tag_map: lì ci sono le associazioni articolotag. Fai sempre un backup prima (anche solo della tabella) e cerca le righe con content_item_id uguale all’ID del tuo articolo e type_alias = 'com_content.article'. Da lì puoi reinserire manualmente le associazioni con i tag_id corretti presi dalla tabella #__tags.
Un consiglio operativo: prima di ripristinare una vecchia versione, annotati i tag attuali (basta uno screenshot della scheda articolo). Così, qualunque cosa succeda, sai cosa rimettere.
Per inciso, se fossi cliente Host.it questo tipo di intervento sul database lo avresti potuto delegare direttamente ai nostri tecnici via ticket: backup della tabella, ispezione delle mappature e ripristino delle associazioni tag fanno parte del supporto specialistico che diamo sui CMS che ospitiamo. Te lo dico perché è proprio uno di quei casi in cui mettere mano al DB senza una rete di sicurezza fa venire il mal di pancia.
Fammi sapere quale versione di Joomla stai usando e se il problema si presenta su tutti gli articoli o solo su alcuni, così possiamo capire se c’è anche qualche estensione di mezzo che peggiora la situazione.​​​​​​​​​​​​​​​​

Lo dico subito così ci togliamo il pensiero: ogni due settimane esce un nuovo tool AI che promette di costruirti un sito "in 30 secondi senza scrivere una riga di codice". Lovable, v0, Bolt, Base44, Replit Agent... la lista si allunga ogni mese.

E intanto su LinkedIn è tutto un fiorire di post tipo "WordPress è finito", "i CMS tradizionali sono dinosauri", "perché pagare uno sviluppatore quando ci pensa l'AI".

Allora facciamo due conti onesti, da gente che con i siti ci lavora davvero.
Cosa fanno bene questi builder AI (perché qualcosa lo fanno)
Prototipi rapidi, landing page usa-e-getta, mockup da mostrare al cliente il lunedì mattina dopo che te lo ha chiesto la domenica sera. Su quello sono effettivamente comodi, inutile negarlo.

Cosa NON fanno (e qui inizia il divertimento)

Un sito multilingua serio con gestione editoriale strutturata
Una community con permessi granulari per 15 gruppi utente diversi
Un e-commerce B2B con listini personalizzati e flussi di approvazione
Migrazione di 8 anni di contenuti SEO senza perdere posizionamenti
Manutenzione, backup, sicurezza, conformità GDPR su progetti veri
Customizzazione di un componente quando il cliente cambia idea per la terza volta

Provate a chiedere a un builder AI di farvi un Joomla con K2 migrato a v4, oppure un WordPress con WooCommerce, Polylang e un tema custom child. Tornate a raccontarmi come è andata.

La domanda vera

Non è "CMS vs AI builder". È: chi sta vendendo cosa, a chi, e per quanto tempo quella cosa starà in piedi?

Un sito Joomla del 2015 oggi gira ancora. Un sito generato da un tool AI di tre anni fa... esiste ancora la piattaforma su cui era stato creato?

A voi la palla

Avete provato a sostituire Joomla o WordPress con un builder AI su un progetto reale (non un esperimento)? Com'è andata?
I clienti ve li stanno chiedendo? Cosa rispondete?

Pensate che tra 5 anni saremo ancora qui a parlare di CMS o avrò perso la scommessa?

Io la mia idea ce l'ho, ma prima voglio sentire la vostra. Sparate.