Ciao e benvenuto 🙂

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

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?

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

ok risolto
hu e' diviso in 2 (template e plugin)
ed e' normale che possono essere disallineati
hu forum

saluti
alla prox

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

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!

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.

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

Pubblicità? Non si tratta, credo di fare pubblicità.
In ogni caso, grazie.

Bene. Aggiornamento della versione effettuato, mi pare che sia a posto.
Vi ringrazio!

Ciao Roberta, è un bel lavoro, ma rimane il neo della modifica a un core file.

Semmai avessi tempo, io ti consiglierei di sviluppare un piccolissimo plugin di tipo system.
Nell'evento onAfterRender puoi accedere al corpo della pagina e fare la sostituzione del nodo radice <rss version="2.0"> con la tua versione ampliata.

My two cents!

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