PHP

[_Alex_]

Ah ok, vediamo se ho capito o se sono 'de coccio'.

Nella situazione in cui sono, qualsiasi utente connesso al Cms, andando nella pagina del form, otterrebbe l'accesso al database ticket "agganciandosi" all'utente Alex specificato nello script php, giusto?

Se è così non devo fare nessuna modifica, solo trovare il modo di mettere la pagina del form dentro il sito, ma credo si risolva.

Per MySql non saprei per quale motivo la sintassi di sopra non andava, allora.

Rispetto ai giorni scorsi ho disabilitato l'IIS (che avevo cercato di utilizzare prima di Xampp) ed ora la porta 80 è libera, l'ho reimpostata in Apache.ini.
Provo a riguardare il file per vedere se trovo qualche impostazione sospetta.

[Andrea Giorgi]

Si, il discorso sugli utenti è corretto.

Per apache guarda che non ci sia un file .htaccess in "C:\Xampp\HtDoc", le direttive per accettare connessioni solo da localhost potrebbero essere anche li dentro.

[_Alex_]

Alla fine era il firewall che bloccava le connessioni in entrata; aperta la porta 80 ha funzionato tutto.

Da domani dovrò perfezionare un pò di cose, per esempio i campi descrittivi devono accettare tutti (o quasi) i caratteri, anche quelli problematici, devo rifare la prova da remoto e controllare se i dati vengono scritti nel db perché di primo acchitto abbiamo usato caratteri speciali e c'era l'alt dello script (poi è finito l'orario lavorativo ), dovrò implementare qualcosa per gli aggiornamenti del ticket di intervento e l'eventuale chiusura, insomma, un bel lavoro ancora da fare

[_Alex_]

Dunque, allo stato attuale le colonne Problema e Descrizione sono varchar(200) e non accettano caratteri speciali.

Per aggirare il problema ho trovato due possibilità dal MySql reference (un libricciolo da 4422 pagine....):
1. TINYBLOB o TINYTEXT
2. l'istruzione QUOTE

Mi è parso di capire che i tipi BLOB e TEXT hanno lunghezza fissa a seconda che si scelga TINY, BIG ecc... ma, più avanti, il manuale indica che vanno trattati alla stregua dei VARCHAR, quindi non dovrei aver bisogno di cambiare il tipo di dato memorizzato (oltretutto sono più libero di scegliere i limiti), invece l'istruzione QUOTE consente di automatizzare l'inserimento del carattere di escape e farlo fare a MySql, però non tutti i caratteri sono accettati, soltanto \ ' NUL e Ctrl+Z, quindi nei campi descrittivi sono comunque fregato, oppure lo spazio viene considerato NUL?

Spero di trovare in fretta un elenco di caratteri sgraditi e, soprattutto, di quelli consentiti nel manualone......

[Andrea Giorgi]

Prova a dare un'occhiata qui:

http://www.toptal.com/php/a-utf-8-primer-for-php-and-mysql

Un altro approccio comunque potrebbe essere quello di codificare le stringhe in PHP prima di scriverle nel DB, successivamente decodificarle sempre nello script PHP che andrà a leggerle. Potresti usare rawurlencode() e rawurldecode().
In questo caso tieniti un po' di caratteri in più nel campo in MySQL.

[_Alex_]

Grazie del link

Per ora ho risolto editando le righe preg_match ed ho aggiunto i numeri, lo spazio era già inserito ed ora il form accetta la stringa senza problemi; non credo di usare la cifratura, non si tratta di dati sensibili e poterli editare dal phpmyadmin mi fa comodo.

Ora mi spulcio il manualone per trovare qualche funzione che restituisca data ed ora e poi passo all'aggiornamento e chiusura dello status di intervento.


Ps: mancano alcune emoticon, si può aggiungere lo smiley che prende appunti?
E, magari, anche qualcosa di più accattivante esteticamente.....

[Andrea Giorgi]

Le funzioni che ti ho indicato non effettuano alcuna cifratura, semplicemente codificano e decodificano i caratteri non alfanumerici che altrimenti non verrebbero interpretati correttamente (spiegazione molto approssimativa, in realtà c'è l'RFC 3986 che ne spiega il funzionamento).
Nascerebbero per passare stringhe nelle url ma dovrebbero andare bene anche nel tuo caso.

Per le date puoi farti un'idea veloce qui se le vuoi implementare in MySQL:

http://www.w3schools.com/sql/sql_dates.asp