Scusate se mi sono intromesso non richiesto.
Anche se non sono attivo cmq vengo spesso a leggere, e una volta tanto potevo dare i soliti 2 cents 
Torno nel mio cantuccio.
Bye, Riccardo.
Ciao Riccardo, grazie per i tuoi pareri e suggerimenti, è sempre bene avere feedback da altre persone
Errore IMHO: se una stringa passa la validazione la query va in errore e si apre una porta a tentativi di SQL-Injection.
Due apici non costano niente, ma rendono la query decisamente più solida.
Lasciando a MySQL la valutazione/conversione del dato al peggio si ottiene che la query non restituisce nessun record.
Anche mettendo gli apici, non sei al sicuro da una SQL-Injection. L'unico sistema sicuro è validare bene le variabili prima di inserirle in una query, soprattutto quando sono variabili prese da form html dove l'utente può inserire ogni tipo di dato.
In questo caso sono valori numerici e non inseriti dall'utente, quindi un cast ad intero o una funzione che prende il valore intero della variabile è già sufficiente.
Comunque qui stiamo andando su temi complicati, per chi non ha mai utilizzato un db meglio procedere un passo alla volta
"or die()" anche se non lo vedo penso che ci sia no? 
Il die() interromperebbe il caricamento dell'intera pagina di joomla, quindi non va utilizzato nei file inclusi in joomla. Meglio gestire l'errore in altro modo
Se posso avrei un suggerimento anche sul punto che segue (premesso che ovviamente non ho idea del resto di questa "cosa" né del motivo preciso per cui viene fatta questa query).
[...]
Se, come immagino, il discorso serve a mostrare in un elenco dei progetti (o nel dettaglio di un progetto) qual'è l'ultimo UOTD registrato, io piuttosto che leggere la tabella in cui vengono conservati, farei un doppio inserimento appena se ne trova uno:
- nella tabella dedicata, con tutti i dettagli del caso,
- nella tabella dei progetti conserverei:
- o il dato che viene letto (CPID/ID utente)
- o l'ID di quel record (se esite) sotto forma di chiave esterna.
In un modo o nell'altro si evita una query su una tabella potenzialmente grande e se dall'ID poi si devono andare a prendere i dati dell'utente, questa cosa può essere fatta "in diretta" nella query precedente (elenco progetti?)
Può essere una soluzione. Quella che ho proposto io è la soluzione più semplice senza duplicazione dei dati, se poi risulterà lenta con l'aumentare dei dati sicuramente ci rimetteremo mano, ma per un pò penso che può andare così
@GHz: primo messaggio da cron arrivato alle 22.50! Ho lasciato un attimino perdere lattice, e ho creato/aggiornato uno script che mostra gli ultimi uotd per ogni progetto, da mettere nella pagina 'Utenti del giorno' in Partecipa->Iniziative.
Ottimo!!! Il progetto migliora sempre di più!
Alcune note grafiche sulla pagina:
- mettere il colspan a 6 invece di 5 altrimenti non torna l'intestazione della tabella.
- alcuni nick non ci stanno, meglio non utilizzare un font più grande. per i font più piccoli prova ad usare il tag <small></small> invece di impostare la grandezza del font, vediamo come viene.
- invece che l'ora di rilevazione metterei solo la data di elezione, tanto l'UOTD cambia ogni giorno, quindi possiamo omettere l'ora
Dal lato codice invece, anche qui si può ottimizzare la lettura dei dati dal db. Invece di fare una query per prendere la lista dei progetti e poi una query per ogni progetto per prendere l'ultimo uotd, possiamo farci tornare i dati che ci servono in una sola query, in questo modo:
$query = "SELECT UOTD.*, progetti.Nome, progetti.HOME FROM UOTD, progetti
WHERE UOTD.Timestamp IN (SELECT MAX(Timestamp) FROM UOTD GROUP BY Project_ID)
AND UOTD.Project_ID = progetti.IDProgetto AND progetti.active = 1";
Se servono altri campi della tabella progetti basta aggiungerli all'inizio della select