E così pare che una delle nuove e più pratiche funzioni apparse nella penultima versione di Movable Type, ovvero il processo di pubblicazione di un post o di un commento più breve a scapito della messa in linea immadiata, fosse un realtà un bug del programma. E così la nuova versione è tornata a richiedere minuti di attesa prima che la pubblicazione del proprio intervento vada a buon fine. E non giova, purtroppo, che parecchi server che hanno installato Movable Type (per quanto protetti da MTBlacklist) siano tartassati dallo spam nei commenti ricevendo centinaia di richieste al minuto.
(Visited 32 times, 1 visits today)
Lo spam, anche se intercettato dalla Blacklist, sottopone comunque il server ad un carico di lavoro notevole. Ho trovato una soluzione semplice ma efficace al problema deviando i messaggi di spam PRIMA che arrivino a Movable Type, evitando che vadano sprecate risorse per elaborare messaggi di spam.
L’idea è di fare puntare il modulo di invio dei commenti ad una directory falsa, solo premendo con il mouse o la tastiera il pulsante di invio un semplice comado Javascript darà al modulo l’indirizzo giusto. Lo spam inviato in automatico da programmi che non usano mouse e tastiera non arriverà mai a Movable Type.
Il giochino è in funzione da una ventina di giorni su Haramlik con il 99% dello spam fermato senza che nessun utente abbia mai avuto problemi di invio dei commenti.
La “trappola antispam” potrebbe essere interessante anche per chi usa Word Press o altri programmi privi di filtro per lo spam.
E non giova neanche che Typekey scassi la wuallera 8634 volte al giorno per rifare il login…
Gianluca, dobbiamo farcene una ragione. MT 3 e’ un cesso. E’ a pagamento, è lento come la morte, e io sono stato costretto a buttarlo via perché la versione su textfile schiantava il server su cui ho l’hosting.
Poi ho scoperto WordPress e la mia vita è migliorata sensibilmente, soprattutto perché importa tutti i messaggi e i commenti in maniera più o meno indolore, ha una nutrita schiera di plugin, e soprattutto non devi ogni volta fare rebuild di tutto perché le pagine sono dinamiche.
Se vuoi ti faccio un corso accelerato ;)
Ho notato anche io la lentezza nei commenti di alcuni siti MT-Powered…
E anche la storia di TypeKey non aiuta, dato che qualche giorno fa era lento anche TK.
WP e’ decisamente piu’ agile, e alla fine il poter moderare senza problemi ne’ rebuild ne’ niente e’ una cosa da tener da conto al giorno d’oggi (anche perche’ spammano un bel po’)
Mi sembra un’ottima idea quella di fantasma…
Dimenticavo di aggiungere che, per chi volesse provare la trappola antispam, posso mettere a disposizione anche un finto modulo “mt-comments.cgi”
da mettere come indirizzo falso che permette di controllare quali messaggi vengono catturati con questo sistema. Questo almeno per i primi tempi, dopo di che si può mettere un indirizzo di pura fantasia affinchè nessuna risorsa del server venga sprecata per lo spam.
Per farsi un’idea: http://www.ilcircolo.net/spam.php
Da notare anche l’assidua presenza dei robot degli spammer a caccia di form di invio.
Fantasma, il metodo è buono, però non è il massimo dell’accessibilità, esistono utenti, se pur pochi, che navigano senza javascript o con javascript disattivato.
A proposito del suggerimento di fantasma, WordPress il filtro per lo spam ce l’ha.
(prima avevo dimenticato)
Il CMS me lo son fatto da solo, ma all’inizio dello sviluppo di MT 3 proposi ai coniugi la semplice soluzione di controllare in automatico gli IP appartenenti agli ultimi X commenti.
Lo spammer classico inonda un blog di commenti in un tempo strettissimo, quindi sarebbe bastata una piccola procedura che eliminasse tutti i commenti N dell’Ip X che fossero stati pubblicati dentro un arco di tempo Y.
se N(x) > Y { radi al suolo i commenti e banna l’Ip }
Non si risolve il problema al 100%, ma al 99 si, e senza casini di registrazioni.
Per quanto riguarda la lentezza, è un problema dovuto al tipo di implementazione che hanno scelto in fase di “prima scrittura”. Se vogliono lo statico a tutti i costi, il rebuild generale con il passare del tempo stramazza un server peggio che un dinamico.
La soluzione è una cache intelligente con rebuild all’occorrenza, cioè la pagina viene fornita dinamicamente alla prima richiesta e contemporanemanete viene resa statica per le visioni successive. L’ unico neo dell’implementazione è la necessità di usare il mod_rewrite di apache.
Se hai un sito trafficato, ti serve un database serio, gestito seriamente. MySQL “tanto va” non è sufficiente, e non credo che software che richiedono una chiamata al database per ogni pagina letta (quando MT va con un file html) risolverebbe il problema, anzi. Consiglio di provare un setup più raffinato del server e/o PostgreSQL.
Mysql con InnoDB E’ un DBMS serio, secondo me e non solo. Ma si va troppo nel tecnico, mi sa che siamo fuori luogo.
Secondo me no, ma non è la questione (anche perché non sappiamo come sia configurato): il punto è che se si hanno una gran quantità di accessi bisogna sistemare il setup di tutto, e fare le ottimizzazioni necessarie. Per quel che ne sappiamo potrebbero anche mancare degli indici. Il senso era: guarda la configurazione del database.
Spiace rivelarvelo così, ma WordPress è un cesso di programma. Installo tutto e provo tutto, io, e posso dirlo con cognizione di causa. Quando a TypeKey che richiede la registrazione ogni due ore, ora chiedo direttamente a quelli di Movable Type, che facciamo prima. MySQL, qui su BlogNation, ha gli indici: vengono ricorstuiti ogni mattina alle 6. Il problema, semmai, è l’alto numero di accessi e lìottimizzazione di tutto il resto.
A tratti compare e scompare sulla destra la voce “Useronline Insert Failed >”…