Ciao @mipo66,
per il test e la licenza, se ti va scrivimi pure in privato: così ci organizziamo con più calma su dominio, installazione e feedback, senza riempire il thread di dettagli operativi.
Qui nel frattempo, se altri della community vogliono provarlo, possono contattarti dal sito come hai indicato.
Ciao, chiaro: fase sperimentale con licenza per dominio ha senso, così non spariscono copie in giro.
Appena riesco lo provo su un Joomla 5/6 di test e ti scrivo qui. Per la richiesta licenza uso la mail indicata sul tuo sito, giusto?
Se nel frattempo altri della community vogliono aiutarti a testarlo, il link alla pagina del plugin basta.
Ciao @mipo66, interessante: a volte Joomla "di base" con PHP Mail va in crisi e un bridge SMTP dedicato sistema tutto.
@Domenico, prima di rifare tutto il sito per le sole mail, vale la pena provare in ordine:
@mipo66, se ti ricordi quale componente hai usato, segnalalo pure: a Domenico fa comodo.
Se il sito è su Host.it, aprendo un ticket i tecnici di solito verificano in pochi minuti se il server sta accettando/inoltrando la posta in uscita.
Ciao Domenico,
l'idea di un Joomla 6 "pulito" in sottocartella + DB nuovo ha senso, soprattutto se in passato hai avuto Community Builder: a volte restano pezzi (tabelle, plugin, override) che sporcano registrazione e mail.
Per non perdere i contenuti, in pratica farei così:
images (e da eventuali cartelle custom) sul nuovo sito: è la parte più semplice e sicura.#__users / #__user_usergroup_map (con attenzione agli ID e ai gruppi). Meglio farlo su un backup, non a caldo sul sito in produzione.Sulle email agli admin: su un'installazione nuova, se continua a non partire, di solito non è "un fantasma di CB" ma SMTP/server. Controlla in Sistema → Configurazione globale → Server (invio mail) e, se puoi, usa SMTP invece di PHP Mail. Su hosting tipo Host.it i tecnici di solito ti dicono subito se la mail dal dominio è ok o se serve autenticazione SMTP / SPF.
Se mi dici versione esatta di Joomla e se usi PHP Mail o SMTP, ti indico i passaggi più stretti.
Ciao @mipo66,
bella iniziativa: un plugin Joomla per gestire i podcast (Spotify, Spreaker, Apple Podcast, YouTube, SoundCloud e via dicendo) era davvero una lacuna sulla JED.
Compatibilità con Joomla 4/5/6 e PHP 7+ è un ottimo punto di partenza. Appena riesco lo provo su un ambiente di test: di solito su hosting con PHP aggiornato queste estensioni si installano senza particolari grattacapi; se uno è su Host.it, per dubbi su versione PHP, permessi o cache, i tecnici di solito danno una mano diretta dal pannello.
Per chi vuole aiutarti a testarlo, sarebbe utile:
Se lo pubblichi anche su GitHub o sulla JED sarà più facile seguire gli aggiornamenti.
Grazie per aver condiviso con la community!
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:
ultimamente ci sono tanti brigantelli... ma ... è strano sei la prima persona che lo segnala!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: httpsall'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:
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:
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. 