se hai acquistato questo plugin si

Personalizzabile, sì.
Credo che si possano nascondere i campi per determinati contatti.
Se è così, ed ho capito cosa intendi per "duplicabile", non dovresti avere problemi.

Facci sapere, che ora che hanno messo un CAPTCHA nel core, sto pensando di passare al modulo contatti standard per il mio sito.

Se funziona bene tolgo tutti i form creati con Convert Forms e torno a quelli standard di Joomla!

Ciao,
se hai elenchi lunghi è un po' più difficoltoso.
Dopo aver selezionato la voce/le voci da spostare devi usare insieme il tasto freccia alta o bassa della tastiera, dipende se vuoi spostarlo su o giù.
Spero sia chiaro.

Grazie, ma ho risolto. In pratica ho ripreso il codice di Vimeo e come per magia tutto è tornato apposto. Gemini ChatGPT e DeepSearch hanno fallito, mi hanno fatto incasinare i files del template, alla fine ho ripristinato tutto con un restore e poi ho rimesso il codice embed di Vimeo ..... altro che AI !!!!

@jeyjey ha detto in Mi presento dopo anni di assenza:

Buonasera mi presento, sono un vecchio utente del vecchio forum ...... provengo da Mambo ..... ora sono di nuovo qui.

Azz! Allora bentornato!

[RISOLTO] Dunque. Dopo aver utilizzato database e files di backup, scaricato Joomla e sovrascritto solo la cartella "Vendor" presente nelle librerie e, infine, svuotato la cache direttamente in Aruba, il sito è di nuovo online. Resta da capire perché tutto questo sia successo!

@matty80 , Si infatti non potevo aggiornare ma nemmeno potevo disinstallare non avrei potuto fare nulla , a meno che non sia un buon conoscitore del database per lavorarci direttamente, ora dopo aver installato il salvataggio fatto tempo fa tutto funziona ed ho ovviamente aggiornato il tutto, grazie comunque per il tuo prezioso interessamento.

Grazie elmir: strumento adottato, facile da usare, ottenuto il risultato cercato.

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:

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.

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.

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. 👍

A me hanno bucato due siti con sta falla jce
Uno joomla 4 l'ho rifatto oggi, partendo da un backup pulito così sono pure passato j 6.1.1
l'altro attendo perchè sarà da rifare completamente (joomla 3)

Da quel poco che ho capito, una volta bucati, i tizi condividono l'url con altri in modo che ognuno posssa fare le iniezioni che crede:
Un sito aveva links ad amazon (credo si possa tracciare il referrer per capire chi intasca i soldini ma dubito che amazon si sbatta per una cosa del genere), l'altro a un casino on line

@Domenico ha detto in [I CMS sono morti?

E' prorpio così Zio, allora avrai avuto tra le mani uno ZX Spectrum degli anni 80

In realtà ho sviluppato un giochino in Basic interpretato su un Commodore PET con 4KB di RAM
https://it.wikipedia.org/wiki/Commodore_PET
che avevo trovato nel Centro di calcolo del Politecnico di Milano nel periodo in cui stavo sviluppando il programma per l'esame di programmazione in Fortran su schede perforate, che girava su di un UNIVAC 1108. 😁
Conservo ancora il cimelio storico delle audio-cassette con i sorgenti del programma.

Comunque, non ho mai smesso di programmare nella mia vita 🙂 e ora programmo per uso personale in Java e mi diverto una cifra. 😳

Dimenticavo: per tornare in argomento...
Anch'io ho un sito che ho realizzato in Joomla secoli fa e sto aspettando che il provider aggiorni la versione del db Sql per poter aggiornare la versione di Joomla dalla 4 alla 6.👍

ok, ho ricontrollato tutto. C'era ancora qualcosa qua e la da sistemare 🙂 . Ora sembra sistemato per bene.
Grazie mille.

@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.