Sì, appena applicato il fix di Brian, tutto risolto!

Probabilmente hai ragione.
Io uso l'htpasswd perché quando il sito è offline e mi loggo come amministratore, nel front-end vedo i pulsanti relativi all'amministrazione.

Sta cosa dei permessi sull'Accesso offline non la conoscevo.
Bel suggerimento! Più tardi provo

Caspita anche a me “lampeggia” l'editor e non riesco a fare modifiche agli articoli
Proprio ieri ho lanciato l'update di alcuni pacchetti su Ubuntu.

Mi tocca usare Chrome - che non sopporto - in daily.
Oppure no, ora provo altri browser...

Mi dispiace, non ne conosco.
Capisco che possa essere “laborioso” per chi ha poca pratica con questo tipo di procedure , ma ti posso consigliare una cosa?

Evita l'installazione di plugin per compiti che puoi fare nativamente con quello che hai già a disposizione.
Ogni plugin che installate aumenta potenzialmente la vulnerabilità del vostro sito web.
Certo senza plugin impiegherai più tempo, ma alla fine avrai anche imparato qualcosa di nuovo

Appena mi libero un pochino lo provo

@webman ha detto in Refresh continuo con TinyMCE:

Avete riscontrato questo comportamento di recente ?
Non e più possibile editare articoli/moduli con l'editor TimyMCE (in Firefox).

Brian Teeman ha pubblicato un hotfix ma per me non funziona.
https://github.com/brianteeman/tinymce-firefoxfix
C'è anche una PR sulla repo di Joomla: https://github.com/joomla/joomla-cms/pull/46889

Ciao @webman
Hai mica abilitato il Content Security Policy nel plugin “Sistem - Intestazioni HTTP”?

@effebicri ha detto in Sito in manutenzione:

Buongiorno a tutti. Mi chiedevo se c'è un modo per modificare il proprio sito joomla online senza fare vedere le modifiche sino a quando si è deciso di utilizzarle. Magari usando un plugins di manutenzione o altro. Grazie

Ciao.
Se il sito gira su hosting Linux e web server Apache, ti basta impostare .htaccess e .htpasswd
A questo punto potrà vedere il sito solo chi ha le credenziali che hai specificato in .htpasswd

Quando vorrai renderlo accessibile a tutti, sarà sufficiente rimuovere il file .htaccess

https://www.aganis.it/siti-web-trento-blog/proteggere-area-web-con-htaccess-e-htpasswd/

Da sviluppatore ti posso consigliare, poi ognuno fa come vuole.

Stai attento quando fai le operazioni CRUD sul database, perché se non passi per un sistema sicuro, tipo il “query chaining” offerto dal framework di Joomla, sei soggetto ad attacchi di SQL injection.

https://manual.joomla.org/docs/security/secure-db-queries/

Se il tuo form non fa parte dell'infrastruttura di Joomla, hai due gestioni diverse.

Ma questo campo data, che roba è?
Perché se è la data odierna, puoi inserirla sul DB direttamente in SQL con l'istruzione MySQL CURDATE()

Se ti serve solo un form che poi invii i dati al DB, non sarebbe meglio usare un'estensione tipo Convert Forms?

Provo e ti faccio sapere

EDIT: Sembra non funzionare. Che poi io su mobile uso anche immagini che vanno in scorrimento orizzontale, senza ridimensionamento. Width 100% in questo caso fa poco.
Niente, situazione troppo complessa per una soluzione veloce.

Misà che il Lazy fa un bel volo fuori dalla finestra

No, la sessione non è condivisa tra più applicazioni.
Se la sessione fosse condivisa ci sarebbe un'enorme problema di sicurezza.

Ciao @jabba
avevo pensato a preimpostare l'altezza, ma credo che per gestirla per il responsive diventi un casotto...

Ciao a tutti.
Negli articoli del mio blog utilizzo una TOC ancorata alle sezioni dell'articolo.
Mi sono accorto che se nell'articolo ci sono delle immagini in lazy load, la prima volta che uso le ancore queste non fanno spostare la pagina nella posizione esatta.

Questo è spiegabile con il funzionamento del lazy load stesso, perché non assegna l'altezza al container <img> se non quando con lo scrolling non si arriva all'immagine stessa, e quindi si sballa tutto il calcolo per arrivare alla sezione corretta.

Qualcuno di voi che si è imbattuto in questo problema ha trovato una soluzione “veloce”?

Filippo, io non ho capito bene, ma se devi comunicare dall'esterno con Joomla, ti consiglio comunque di passare attraverso le API.
Utilizzare codice PHP embeddato nell'articolo, senza utilizzare il pattern architetturale di Joomla è una cosa che non si fa, perché mandi a farsi friggere tutto il layer di sicurezza e le ottimizzazioni del framework del CMS.

Poi magari ho capito male io eh... magari spiega meglio il progetto, così possiamo darti una mano più concreta.

Litespeed è un altro che mi ha dato problemi.
Redis non lo conosco... vedo di provarlo nei prossimi giorni

Riapro questa discussione perché proprio ieri ho pubblicato un articolo sulla Negative SEO in Joomla.

All'interno spiego - attraverso esempi pratici - le debolezze del plugin System SEF di Joomla, in particolar modo per i contenuti duplicati e per lo spam injection sia tramite parametri extra che tramite le query dello Smart Search.

Sono due argomenti che ho affrontato durante lo sviluppo del mio plugin per canonical URL.

Per chi fosse interessato all'argomento, potete leggere l'articolo a questo indirizzo:

https://www.htmlcrusco.it/blog/negative-seo-e-joomla-come-scongiurare-uno-degli-attacchi-piu-dannosi

Mai visto un sistema di caching che non crei “problemi”.
L'ultimo che ho provato è JCH Optimize.
Ma già il sistema built-in di Joomla! può essere fastidioso.

Se siete persone che usano Joomla (ma vale per qualsiasi CMS) è impossibile che non vi siate imbattuti in almeno un modulo che non aggiorna i contenuti.

Proprio ieri ho sbattuto la testa con un cliente che si lamentava che uno dei moduli mostrava dati non aggiornati.
Naturalmente era la cache il problema... ma vai a capire quale?
Sul suo sito web era installato di tutto, e giravano più sistemi di caching in contemporanea.
Alcuni continuavano a salvare qualcosa anche se disabilitati.

Solo dopo tre ore ho trovato il colpevole: il template - basato, ahimé, su uno dei framework più utilizzati oggi - aveva un proprio sistema di caching e memorizzava (non chiedetemi perché), i dati su file json.

Per non parlare poi della cache del browser!
Vai a spiegare ai clienti che se non vedono le modifiche apportate al sito web è colpa del loro browser.
Spiegagli come fare il clear o un hard refresh.

No, no, per carità.
Mi dispiace ma sulla mia bilancia Pro vs Contro, il risultato non lascia adito a dubbi.

Sicuramente altri avranno avuto esperienze migliori.
Tu che sistemi consigli?

Ciao.
Io evito il caching come la peste.
Puoi guadagnare un secondo sulla velocità di caricamento, ma ti ritrovi con contenuti che non si aggiornano.

Il GZIP, il lazy loading e il minify vanno bene,ma occhio che il secondo non è gestito sempre correttamente.
L'eventuale plugin deve essere sempre aggiornato e supportare le ultime regole CSS e JS, altrimenti rischi di avere script non funzionanti e template sballati.

Una cosa importante, da mia esperienza, è non affidarsi troppo ai vari Builder, perché accrescono la pesantezza del DOM e di conseguenza i tempi di rendering e il caricamento della pagina HTML: meno nidificazioni = più velocità.

Fatto!

Se disabiliti il plugin di retrocompatibilità ti riappare l'errore.
com_search e relativi moduli non sono più supportati nelle nuove versioni di Joomla.
Devi disabilitarli o - meglio - disinstallarli, e sostituirli con la nuova infrastruttura Smart Search.