Ciao e benvenuto 🙂

Lo dico subito così ci togliamo il pensiero: ogni due settimane esce un nuovo tool AI che promette di costruirti un sito "in 30 secondi senza scrivere una riga di codice". Lovable, v0, Bolt, Base44, Replit Agent... la lista si allunga ogni mese.

E intanto su LinkedIn è tutto un fiorire di post tipo "WordPress è finito", "i CMS tradizionali sono dinosauri", "perché pagare uno sviluppatore quando ci pensa l'AI".

Allora facciamo due conti onesti, da gente che con i siti ci lavora davvero.
Cosa fanno bene questi builder AI (perché qualcosa lo fanno)
Prototipi rapidi, landing page usa-e-getta, mockup da mostrare al cliente il lunedì mattina dopo che te lo ha chiesto la domenica sera. Su quello sono effettivamente comodi, inutile negarlo.

Cosa NON fanno (e qui inizia il divertimento)

Un sito multilingua serio con gestione editoriale strutturata
Una community con permessi granulari per 15 gruppi utente diversi
Un e-commerce B2B con listini personalizzati e flussi di approvazione
Migrazione di 8 anni di contenuti SEO senza perdere posizionamenti
Manutenzione, backup, sicurezza, conformità GDPR su progetti veri
Customizzazione di un componente quando il cliente cambia idea per la terza volta

Provate a chiedere a un builder AI di farvi un Joomla con K2 migrato a v4, oppure un WordPress con WooCommerce, Polylang e un tema custom child. Tornate a raccontarmi come è andata.

La domanda vera

Non è "CMS vs AI builder". È: chi sta vendendo cosa, a chi, e per quanto tempo quella cosa starà in piedi?

Un sito Joomla del 2015 oggi gira ancora. Un sito generato da un tool AI di tre anni fa... esiste ancora la piattaforma su cui era stato creato?

A voi la palla

Avete provato a sostituire Joomla o WordPress con un builder AI su un progetto reale (non un esperimento)? Com'è andata?
I clienti ve li stanno chiedendo? Cosa rispondete?

Pensate che tra 5 anni saremo ancora qui a parlare di CMS o avrò perso la scommessa?

Io la mia idea ce l'ho, ma prima voglio sentire la vostra. Sparate.

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?

non è il massimo, ti consiglio di chiedere supporto direttamente a loro 🙂

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

saluti
alla prox

@mcanonic ha detto in Inserire una immagine dentro ad un articolo:

Ho provato ad inserire una immagine dentro un articolo, con il semplice pulsante che c'è sotto la parte di editor. E' un png (jpeg mi dice non essere supportato) ma quello che ottengo è questo:
https://www.rivaronesi.it/index.php/pastasciutta-antifascista
ovvero solo la parola in fondo all'articolo con il nome del file. Cosa sbaglio?

Ciao @mcanonic,
l'immagine non è raggiungibile, o non esiste o è in un cartella protetta (magari eventgallery protegge le proprie cartelle da accesso esterno)
Io proverei a linkare una immagine fuori dalla cartella "eventgallery" almeno per capire se è quello il problema.

Ciau!

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,

domanda più che legittima, ci si casca facilmente. La risposta breve è: sì, il rischio c'è, e il fatto che la pagina non sia associata a nessuna voce di menu non ti mette al riparo. Te lo spiego.

L'URL del tipo component/sppagebuilder/page/55 è raggiungibile a prescindere dal menu. Google non ha bisogno di una voce di menu per trovare una pagina: gli basta un link interno (anche un modulo "articoli correlati", una sitemap generata in automatico, un riferimento accidentale nel codice) oppure semplicemente il fatto che SP Page Builder, di default, popola la sitemap XML con le pagine pubblicate. Se hai OSMap o la sitemap nativa attiva, quella pagina ci finisce dentro senza che tu te ne accorga, e da lì a Search Console il passo è breve.

Quindi il "non è nel menu = è invisibile" purtroppo è un mito che gira parecchio nei forum.

Per lavorare in pace sul sito pubblico hai un paio di strade, dalla più semplice alla più solida:

La cosa più rapida è tenere la pagina in stato Unpublished finché non è pronta. Una pagina non pubblicata non è raggiungibile dal frontend né finisce in sitemap. Costruisci tutto, la rendi pubblica solo all'ultimo. È l'approccio che consiglierei nel 90% dei casi.

Se invece hai bisogno di vederla pubblicata per testarla "dal vivo" (anteprime, comportamento reale, eventuali script di terze parti), allora la blindi a livello server. Nel tuo .htaccess puoi escludere quello specifico path dall'indicizzazione, oppure agire via robots.txt aggiungendo una riga tipo:

Disallow: /component/sppagebuilder/page/55

Tieni presente che robots.txt chiede a Google di non scansionare, ma se la pagina è già stata linkata da qualche parte potrebbe comunque comparire come URL "spoglio". La soluzione davvero a prova di bomba in quel caso è un meta tag noindex sulla pagina (SP Page Builder lo permette dalle impostazioni SEO della singola pagina, nella tab Options → Meta Data), che è il segnale più chiaro e definitivo che puoi dare.

In sintesi: se non ti serve vederla live, Unpublished e dormi sereno. Se ti serve live, noindex sulla pagina è la mossa giusta.

Un'ultima cosa sull'URL localhost che citi: quello vale solo sulla tua macchina, sul sito pubblico l'URL avrà il tuo dominio reale, quindi non preoccuparti di "esportare" quel riferimento, cambia da sé in base al dominio su cui giri.

Te lo dico per esperienza: questo tipo di dubbi, quando si lavora direttamente in produzione, è il classico caso in cui avere qualcuno che ti controlla al volo la configurazione SEO e la sitemap fa la differenza. Sui server Host.it questo genere di verifica i nostri tecnici la fanno tranquillamente su richiesta, proprio per evitare brutte sorprese in Search Console.

Facci sapere come va!

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.

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
😉