RISOLTO 5.2-chat che scompare/inutilizzabile

RISOLTO 5.2-chat che scompare/inutilizzabile postato il 23/01/2014 08:35:56 nel forum programmazione, gdrcd e open source e modificato da carmillah il 31/01/2014 14:18:52

Come da oggetto capita in maniera randomica e difficilmente individuabile anche dai log della tabella "chat"

il problema non è nell'insert nel database, la riga viene inserita perfettamente formattata (e infatti copiando e incollando il "testo" in un secondo momento non ho gli stessi problemi, l'orario è giusto etc)

succede che qualcuno mandi un'azione che per qualche motivo non visibile ad occhio umano (almeno dal mio <.<) risulta "problematica".
rimuovendo le azioni "problematiche" e aggiornando nuovamente la chat questa riappare senza problemi (o anche svuotando i log)
se invece non rimuovo questa azione "buggata" la chat rimane inutilizzabile per 30 minuti (ovvero il tempo che ha la select delle righe di eliminarla da sola da quelle gestite)

ho già gestito la stanza "-1" in cui il pg inviava l'azione in caso di apertura in un altro tab di una mappa cliccabile, ho già gestito la ripetizione di insert della stessa identica riga (per la serie "pg che invia 24 volte di seguito" che pareva generare il problema), ho già gestito con un

$chat_message=str_replace(array("
r", "
n"), "", $chat_message);

il problema di invio di line-breaks e linee vuote (ho sostituito la input text con una textarea in chat quindi talvolta Chrome è più rapido del mio Javascript che intercetta il tasto invio)

Sono un poco a corto di idee!


non so se il problema sia già stato sollevato, in quel caso chiedo venia (o un diametro piccolo per i sassi della lapidazione u.u )

quota

23/01/2014 11:05:47

Ciao. Ho riscontrato e risolto un bug simile a questo nella versione del GDRCD 5.0. In quel caso si trattava di righe vuote inviate in chat (presumibilmente con copia incolla da word) che per qualche strano motivo impedivano il refresh della pagina. Sul database la riga vuota si vedeva nel record, era proprio un "a capo".

Se si tratta dello stesso problema, contattami in privato e ti spiego come l'ho risolto. :-)

http://newyorknewyork.altervista.org/

quota

23/01/2014 11:35:31 e modificato da blancks il 23/01/2014 11:36:32

L'unica cosa che al momento mi viene in mente sono i line-breaks per l'appunto.

Se riesci a riprodurre l'errore, apri firebug (o gli strumenti da sviluppatore del browser che utilizzi) e verifica che non ci siano errori da javascript del tipo "unterminated literal string" o simili.


@newyork: se non ricordo male il problema degli invii vuoti è riparato già dalla 5.1

Storie di Agarthi ↗
Un Varco si apre davanti a te, un mondo tra i mondi è a portata di mano. Lasciati alle spalle le certezze, diventa quello che hai sempre cercato.

quota

23/01/2014 11:51:57 e modificato da carmillah il 23/01/2014 11:53:04

Come vi dicevo per i break e i rimandi a capo ho già approntato un replace... a cui senza remore ho aggiunto anche un trim per evitare spazi involontari... giusto per

Stamattina presa da forte disperazione ho fatto un passo ulteriore con ut8_encode in entrata e decode in uscita (quando stampa le righe vere e proprie) perchè il problema infatti si è verificato almeno a una persona che incollava da Word
(ad esempio al posto dei ... mette il … ) ... in quel caso forse con l'utf8 già mi dovrei salvare...

quota

23/01/2014 12:15:08

lo str_replace è inutile dato che trim toglie anche tutti i ritorni a capo.

Domanda: quale versione di GDRCD5.2 hai scaricato? Negli ultimi aggiornamenti sono state inserite delle modifiche nel file che tratta le azioni in ingresso, non vorrei che si siano riaperti vecchi bug (anche se non mi sembrava).

Blancks, ha ragione...se si blocca tutto può essere causato da un errore javascript, ma devi consultare la tua console javascript sul browser per identificare l'errore esatto.

Infine un consiglio: per la textarea, se succede che chrome è "più veloce" del tuo javascript, significa che stai agendo sull'evento sbagliato. Per trattare i campi prima di inviarli devi agire sull'evento onSubmit, altri eventi (tipo onKeypress) non hanno garanzia di venire lanciati prima del submit.

quota

23/01/2014 13:48:32

L'ho scaricata da Github attorno ad Agosto, identificate le release in maniera più dettagliata in qualche file ?
dal licenza.txt noto solo 5.2 "Stable"

come maggiore info, oltre le mie modifiche, te la identificherei perchè nel ref_header_inc trovo :

quota

23/01/2014 15:31:50

Agosto è sicuramente prima della modifica, quindi possiamo escludere il problema.

Facci avere gli errori della console javascript

quota

23/01/2014 15:56:29 e modificato da leoblacksoul il 23/01/2014 16:04:11

In effetti chi ha scritto la logica dei messaggi di chat non ha pensato che potrebbero contenere ritorni a capo, ho appena inserito una correzione nel nuovo codice di GDRCD5.2 così in futuro altri non avranno problemi del genere. https://github.com/GDRCD/GDRCD/commit/370c0fc54f5a71479b40e281cad2a3a43e1c8d37
Ma non sembra essere questo il problema dell'autore di questo thread

quota

23/01/2014 17:08:05 e modificato da carmillah il 23/01/2014 17:14:59

In effetti ci sono alcune lacune sulla gestione del $chat_message in input che essendo una ver 5.2 mi hanno lasciato talmente perplessa che ho scritto qui solo dopo due settimane di prove...

ero convinta che fosse impossibile che a questa versione non ci fossero almeno altri 30/50 gestori che non avessero riscontrato il problema... e quindi chiesto qui
io di mestiere non programmo e nonostante le domande che si trovano qui siano di livello easy avevo presupposto di essere l'unica scema a non saper risolvere <.<

Comunque stamattina ho sia trimmato che utf8encodato... vi aggiorno se il problema si ripresenta


[ add ] ho messo anche il json_encode come corretto su Github

quota

31/01/2014 14:19:30

Dopo le fix la situazione è totalmente risolta, grazie mille a tutti.

quota