Problema con estensione Convert Forms

ste981

*AGGIORNAMENTO: MODIFICATO IL POST CON DISCUSSIONE SU PROBLEMA CONVERT FORMS
Salve a tutti, sto testando l'estensione Convert Form per l'inserimento del tasto obbligatorio per il recesso.

Il problema è questo: cliccando su invia richiesta il form non parte, resta in sospeso e la console mi riporta l'errore in foto.

Tutto è configurato al meglio su Joomla, compreso il Forza HTTPS intero sito. L'assistenza dell' host (che ha anche controllato il file .htaccess) mi dice che è colpa di convert Form che produce l’action del form in HTTP, mentre L'assistenza di Convert Form dice che la colpa è del server che risponde con un reindirizzamento che rimanda la richiesta a http!

Avete qualche idea??

mangi-1

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.

ste981

Grazie per le informazioni dettagliate!
Al momento uso solo il modulo contatti nativo di Joomla.
Avrei proprio bisogno di un form con caratteristiche da te descritte. Quello più semplice tra i citati sembra Convert Forms e ho provato a installarlo e configurarlo adesso.
Purtroppo però sorge un problema: quando clicco INVIA RICHIESTA non fa nulla, il tasto fa scorrere i puntini di attesa ma resta bloccato lì!
Ho controllato un po' di impostazioni del modulo e di Joomla, ma non ne vengo a capo. Però il modulo contatti nativo di Joomla funziona, quindi gli invii mail dovrebbero partire.

form reso.JPG

mangi-1

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.

ste981

Ciao,
Punto 1, la console dice questo:

modulo-di-reso.html:1 Mixed Content: The page at 'https://www.crear-arredi.it/modulo-di-reso.html' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint '
http://www.crear-arredi.it/component/convertforms.html?task=submit'. This request has been blocked; the content must be served over HTTPS.

per gli altri punti:
Cache ho solo quella di Joomla, ma provai anche a disabilitarla.
Non ho ancora attivato nessun re-Chapta
Sono su Host di Ergonet

Grazie!

mangi-1

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.

ste981

Buongiorno,
Rieccomi!
Putroppo nessuno dei 3 punti sopra risolve il problema! Tutto è configurato a dovere, anche secondo l'assistenza di Ergonet. Essi mi dicono che il problema risiede nell'estensione.

Mentre L'assistenza di Convert Forms dice che il problema non risiede in convert forms!

pietro strada

Se indica come problema "contenuti misti" vuol dire che hai qualche pagina ancora in http, ricontrolla comunque l'invio se configurato correttamente, quando dai enter resta impallato (sto provando adesso)

mangi-1

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.

ste981

*AGGIORNAMENTO: MODIFICATO IL POST CON DISCUSSIONE SU PROBLEMA CONVERT FORMS

mangi-1

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.