[GDRCD] Possibili problematiche passando a nuovo hosting

[GDRCD] Possibili problematiche passando a nuovo hosting postato il 17/05/2026 21:11:20 nel forum caso altervista e modificato da moderazione il 24/05/2026 13:53:39

Questo topic vuole raccogliere una serie di problematiche comuni e come risolverle per supportare i gestori di giochi basati su GDRCD nel cambio di hosting durante l'alterpocalypse.

Inizio con alcuni punti noti, ma se incappate in altri problemi non riportati qui sarebbe utile segnalarli e indicare le operazioni con cui avete risolto. Mi occuperò poi di tenere aggiornato il topic principale.


#1 - Comparsa di warning/notice error improvvisi dopo il cambio di hosting

Altervista tipicamente nasconde gli errori di una certa gravità di default.
Se avete una vecchia versione di GDRCD è possibile che non abbiate nel codice l'istruzione che consente di ridefinire gli errori che vengono riportati da PHP.

In tal caso, dovrebbe essere sufficiente inserire questa istruzione nelle prime righe del file config.inc.php

error_reporting(E_ERROR | E_PARSE);

#2 - Cloudflare o altre CDN attive di default

Questi servizi si frappongono fra voi e l'utente e mascherano l'ip reale degli utenti che frequentano il vostro sito in quanto si presenteranno tutti, o quasi, con lo stesso indirizzo IP.

Pertanto, quando un utente sbaglia tante volte la password e finisce nella blacklist automatica di GDRCD vi bloccherà l'accesso per tutti gli utenti.

Il fix è di disattivare il CDN tramite il pannello del vostro nuovo provider.
In alternativa, bisogna disattivare la blacklist automatica commentando la riga di codice che potete trovare in login.php a questa riga:
https://github.com/GDRCD/GDRCD/blob/master/login.php#L125 ↗

Nello specifico è questa la parte interessata:

gdrcd_query("INSERT INTO blacklist (ip, nota, ora, host) VALUES ('".$_SERVER['REMOTE_ADDR']."', '".$login1." (tenta password)', NOW(), '".$Host."')");

Grazie @dyrr per la segnalazione di questa problematica.


#3 - Problemi con query di aggregazione che fanno uso del GROUP BY

Versioni più moderne di MySQL potrebbero darvi errore se avete scritto in maniera incorretta delle queries al database che fanno uso della clausola GROUP BY per i dati aggregati.

Il problema si verifica tipicamente quando nella SELECT vengono indicate delle colonne non aggregate che MySQL non ha idea di come compattare nella query.

Faccio un esempio:

SELECT nome, id, COUNT(*) FROM araldo_letto GROUP BY nome

In questo caso, stiamo provando a chiedere al database di dirci per ogni "nome" presente, preso univocamente, quante righe ci sono che lo referenziano nella tabella araldo_letto. Per fare questo passaggio MySQL aggrega tutte le righe con lo stesso nome per formare i risultati, in modo da non ritornare due volte uno stesso nome:

nome | id | COUNT(*)
Super | ? | 10
Test | ? | 4
Blancks | ? | 2

Il problema si verifica in questo caso perché la colonna "id" non è un dato aggregato. Significa che per ogni nome, esistono un numero variabile di righe che hanno un valore diverso di id e mysql non ha idea di quale valore ritornare nella richiesta.

Il modo più semplice di risolvere, in questo caso, è di usare la funzione MySQL ANY_VALUE() che indica al database di recuperare uno qualsiasi dei valori disponibili per quella colonna.

Per esempio, correggendo l'esempio di prima:

SELECT nome, ANY_VALUE(id) AS id, COUNT(*) FROM araldo_letto GROUP BY nome

Grazie @dyrr per la segnalazione e il fix di questa problematica.


#4 - ARUBA: Ho modificato un file ma le modifiche non appaiono/ho risolto un errore, ma questo ancora esiste anche se ho modificato il file

Per gli hosting linux di nuova attivazione, Aruba ha un servizio chiamato HiSpeed Cache attivo di default.

Questo servizio sembra mettere in cache una versione precedente dei files php sul sito e questa cache sembra durare circa 12h.

Se incappate in questo problema durante la modifica dei files dovete ricordarvi di svuotare questa cache dal pannello di controllo affinché tali modifiche abbiano effetto, qui:

Pannello di controllo > Velocità > Caching


E' possibile confermare che il problema sia effettivamente questo servizio di Aruba ispezionando la richiesta con la network console del browser e verificare la presenza del seguente header tra quelli di risposta:

x-aruba-cache: HIT

Grazie @udgdr per la segnalazione del problema!


#5 - Gestione IPv6

Il problema riguarda gli indirizzi IP versione 6 che le attuali versioni di GDRCD non supportano nativamente a causa di un campo troppo restrittivo nelle tabelle personaggio e blacklist. Questo errore si riscontra in fase di login tipicamente.

Questo fix è pertanto consigliato a tutti, a prescindere dal cambio di hosting.

La soluzione è di cambiare le definizioni nel database per poter accogliere gli IPv6. A questo fine bisogna aprire PHPMyAdmin o lo strumento equivalente con cui esplorate il database, aprire una scheda SQL e inviare le seguenti queries:

ALTER TABLE personaggio MODIFY last_ip VARCHAR(45);
ALTER TABLE blacklist MODIFY ip VARCHAR(45);

Se avete utenti che hanno riscontrato questa problematica è possibile che siano rimasti bloccati con date invalide nel database che facciano fallire i controlli attuati in fase di login.

Per risolvere questa situazione, è necessario lanciare le seguenti queris in modo analogo alle precedenti:

UPDATE personaggio
SET ora_entrata = CURRENT_TIMESTAMP
WHERE ora_entrata < '1000-01-01 00:00:00' OR ora_entrata IS NULL;

UPDATE personaggio
SET ultimo_refresh = CURRENT_TIMESTAMP
WHERE ultimo_refresh < '1000-01-01 00:00:00' OR ultimo_refresh IS NULL;

UPDATE personaggio
SET ora_uscita = CURRENT_TIMESTAMP
WHERE ora_uscita < '1000-01-01 00:00:00' OR ora_uscita IS NULL;

Grazie @udgdr per la segnalazione e il fix del problema!


#6 - ARUBA: "Sessione scaduta" succede troppo di frequente

Si tratta molto probabilmente di un problema di configurazione del server di Aruba.
L'azione consigliata è di aprire un ticket chiedendo supporto sul problema.

I dati presenti nella sessione degli utenti ( $_SESSION ) sono tipicamente salvati all'interno di files sul server e questi vengono scritti all'interno di una cartella che viene periodicamente svuotata di quelli più vecchi.

Il problema in questo caso è una configurazione poco lungimirante di Aruba su quel server può far si che le sessioni vengano eliminate anche quando attive, scollegando di fatto gli utenti malcapitati che stanno usando la sessione cancellata in quel momento.

Il seguente fix serve a risolvere provvisoriamente il problema e sarebbe da rimuovere nel momento in cui si arriva ad una soluzione tramite il ticket di assistenza col servizio clienti.

La soluzione è quella di creare una cartella temporanea sul proprio spazio in cui archiviare le sessioni, ad esempio:
/includes/sessions

A quel punto, nel file /includes/required.php inserire la seguente riga prima del session_start():

session_save_path('/web/htdocs/www.tuosito.it/home/includes/sessions');

Infine, l'ultima cosa da fare è impedire che la cartella possa essere esplorata tramite browser per ragioni di sicurezza.

Per fare questo, bisogna creare dentro la cartella /includes/sessions un file chiamato .htaccess. Questo file deve avere questo contenuto:

Require all denied

Se la richiesta di supporto tramite il servizio clienti dovesse rilevarsi infruttuosa va realizzato uno script che effettui la pulizia dei vecchi files di sessione periodicamente.

/includes/cleanup_sessions.php

<?php
// numero di ore oltre il quale cancellare i files di sessione inattivi
$deleteAfterHours = 24;

// cartella dove i files di sessione vengono salvati
$folder = '/web/htdocs/www.tuosito.it/home/includes/sessions';


// logica di pulizia: oltre questo punto non bisogna toccare nulla

$deleteTime = time() - ($deleteAfterHours * 3600);
$handle = opendir($folder);

if ($handle === false) {
trigger_error('Impossibile esplorare la cartella per la pulizia delle sessioni inattive. Sei sicuro il percorso esista?', E_USER_WARNING);
die();
}

try {

while (($file = readdir($handle)) !== false) {
// skip se il nome non inizia per "sess_"
if (!str_starts_with($file, 'sess_')) {
continue;
}

$filename = $folder . '/' . $file;

// skip se non è proprio un file (es: una cartella)
if (!is_file($filename)) {
continue;
}

$mtime = filemtime($filename);

// skip se filemtime fallisce per qualunque motivo
if ($mtime === false) {
continue;
}

// skip se non sono ancora passate le ore di inattività configurate
if ($mtime > $deleteTime) {
continue;
}

// elimina il file
unlink($filename);
}

} finally {
closedir($handle);
}

Una volta salvato bisogna configurare da pannello di Aruba la pianificazione automatica per lanciare lo script in:

Hosting Linux > Processi Cron > Aggiungi Cron

Il comando da configurare, impostato per funzionare una volta ogni 24h, è il seguente:

/usr/bin/php /web/htdocs/www.tuosito.it/home/includes/cleanup_sessions.php

Grazie @neworleans per la segnalazione del problema e per le soluzioni condivise!


#7 - Gestione Luoghi: errore "Incorrect datetime value"

Il problema dipende da come viene "assemblata" la data nelle query di INSERT e UPDATE presenti nella pagina:

I dati year, month e day, quando le privaterooms sono configurate su OFF, vengono implicitamente definiti in questo modo:

<input type="hidden" name="day" value="00">
<input type="hidden" name="month" value="00">
<input type="hidden" name="year" value="0000">

All'interno delle query di INSERT e di UPDATE presenti in quella pagina, queste informazioni vengono composte in questo modo:

'".gdrcd_filter('num', $_POST['year'])."-".gdrcd_filter('num', $_POST['month'])."-".gdrcd_filter('num', $_POST['day'])." 00:00:00'"

Il problema è che gdrcd_filter con tipologia num trasforma il tipo del dato da stringa a intero.

Nel concreto, accade che un valore stringa come 0000 viene quindi interpretato come 0. Per cui si ottiene una data finale che è quella confermata dal messaggio d'errore: 0-0-0 00:00:00.

Il fix più semplice è di cambiare la tipologia di filtro da num a in nelle due queries della pagina in cui viene definita questa data:

'".gdrcd_filter('in', $_POST['year'])."-".gdrcd_filter('in', $_POST['month'])."-".gdrcd_filter('in', $_POST['day'])." 00:00:00'"

Il problema può presentarsi sul nuovo servizio di hosting perché è possibile che le configurazioni del database mysql siano più stringenti rispetto a quelle di altervista.

Grazie @demonhantagdr per la segnalazione del problema!

18/05/2026 20:07:18 e modificato da moderazione il 18/05/2026 20:07:54

Grazie blankse dyrr! Ottimo lavoro!

19/05/2026 19:40:55

gdr-online.com ha scritto: Grazie blankse dyrr! Ottimo lavoro!

Grazie a te!

---

Ne approfitto per comunicare che ho aggiunto il fix di una nuova problematica relativa agli hosting linux di nuova attivazione su Aruba ( il punto #4 )!

Non avendo un hosting linux su aruba non posso controllare di persona ma se qualcuno trovasse il modo di disattivare del tutto quella feature sarebbe utile farcelo sapere rispondendo qui o scrivendo in privato, come preferite.

Grazie a tutti!

19/05/2026 21:41:47

Anche io modificando i luoghi su Aruba ho trovato un errore, questo nello specifico:

Praticamente se provo a modificare un luogo non me lo fa fare a causa di una data settata in modo incompatibile immagino! Y:Y Grazie Blanks per aver aperto questo Thread, almeno a me, molto utile perché ho trovato gli stessi errori (e corretto) segnalati da chi sopra di me! :)

19/05/2026 22:24:23 e modificato da udgdr il 19/05/2026 22:30:06

demonhantagdr ha scritto:
Anche io modificando i luoghi su Aruba ho trovato un errore, questo nello specifico:

Incorrect datetime value: '0-0-0 00:00:00' for column 'scadenza' at row 1

Praticamente se provo a modificare un luogo non me lo fa fare a causa di una data settata in modo incompatibile immagino! Y:Y Grazie Blanks per aver aperto questo Thread, almeno a me, molto utile perché ho trovato gli stessi errori (e corretto) segnalati da chi sopra di me! :)

Ciao! Anche noi abbiamo avuto lo stesso problema, ma con la tabella 'personaggio' nel campo 'last_ip'.

Noi abbiamo risolto prima eseguendo una query di pulizia, poi una query di modifica. Nel nostro caso il problema sorgeva a causa del fatto che il nostro campo 'last_ip' non era pensato per gli ipv6 quindi dava errore e bloccava il login di alcuni account.


Query di pulizia da lanciare per prima:

UPDATE personaggio
SET ora_entrata = CURRENT_TIMESTAMP
WHERE ora_entrata < '1000-01-01 00:00:00' OR ora_entrata IS NULL;

UPDATE personaggio
SET ultimo_refresh = CURRENT_TIMESTAMP
WHERE ultimo_refresh < '1000-01-01 00:00:00' OR ultimo_refresh IS NULL;

UPDATE personaggio
SET ora_uscita = CURRENT_TIMESTAMP
WHERE ora_uscita < '1000-01-01 00:00:00' OR ora_uscita IS NULL;

Query di modifica:

ALTER TABLE personaggio MODIFY last_ip VARCHAR(45);

Lasciamo qui come abbiamo risolto nella speranza possa aiutare altri che hanno questo problema e possa aiutare anche te con una soluzione similare per la tua tabella.

20/05/2026 09:05:12 e modificato da blancks il 20/05/2026 09:10:19

udgdr ha scritto: Ciao! Anche noi abbiamo avuto lo stesso problema, ma con la tabella 'personaggio' nel campo 'last_ip'.

Grazie mille per la segnalazione! Ho aggiornato il topic principale con questo nuovo punto e a questo proposito segnalo che anche il campo ip nella tabella blacklist andrebbe modificato allo stesso modo.

demonhantagdr ha scritto: Anche io modificando i luoghi su Aruba ho trovato un errore, questo nello specifico:

Grazie per la segnalazione! Il problema sembra slegato a prima vista da quello segnalato da @udgdr, non appena mi sarà possibile provo ad indagare sulle possibili cause.

Nel frattempo suggerirei di provare a normalizzare la situazione sul database con questa query inviata tramite PHPMyAdmin e vedere se questo risolve il problema (potrebbe trattarsi di una formattazione del dato errata in fase di reinvio del form quando sul database si trovano salvate date come 0000-00-00 00:00:00):

UPDATE mappa SET scadenza = CURRENT_TIMESTAMP WHERE scadenza IS NOT NULL AND scadenza < '2000-01-01 00:00:00'

In caso questa operazione non sia risolutiva (e nessun altro riesce a scoprire l'esatta causa prima) proverò a dare un occhiata più approfondita in serata.

20/05/2026 09:33:25

Ordunque noi abbiamo avuto qualche rottura di bolas con il "sessione scaduta"
in pratica il session.save_path da come valore /tmp Non son programmatore e spiego un po' in modo semplicistico. quel parametro pare sia quello che a noi da problemi e a random casuale fa scattare il sessione scaduta.

Come lo abbiamo risolto.
Intanto crando un file php_info.php
inserendo nel file questo codice

<?php phpinfo(); ?>

Caricato nel main e aperta la pagina www.tuosito.it/php_info.php
questo ha aperto tutte le informazioni sul php e appunto alla voce
session.save_path avevamo /tmp

Non c'era modo di eliminarlo e correggerlo proprio non son riuscito a fargli digerire il cambiamento e ho ovviato andando a toccare il required con una patch (in includes)
ho inserito la cartella vuota sessions e corretto required inserendo un session prima sello start.

session_save_path('/web/htdocs/www.tuosito.it/home/includes/sessions');
session_start();

Spero di aver fatto tutto in modo regolare, il sessione scaduta è scomparso da 12 ore (da quando ho messo la patch), la cartella sessions lavora correttamente. E' un bypassare ma par aver stabilizzato quello che era il nostro problema principale ovvero la sessione scaduta a casaccio quando si cliccava una pagina qualsiasi (non un file specifico)

se ho fatto minchiate (possibilissimo) alzo le mani e ritiro tutto XD son un principiante che si barcamena.

20/05/2026 14:22:37

neworleans ha scritto: se ho fatto minchiate (possibilissimo) alzo le mani e ritiro tutto XD son un principiante che si barcamena.

La tua soluzione funziona per tamponare nell'immediato ma per stare sereni sul lungo termine consiglio di esporre il problema ad Aruba mediante ticket di assistenza spiegando che le sessioni in /tmp vengono cancellate arbitrariamente ogni due ore e che hai dovuto elaborare il workaround di salvarle in una cartella pubblica del tuo spazio web.

Questo perché è ampiamente probabile che una configurazione di pulizia sul server di Aruba sia sbagliata e significa che probabilmente il garbage collector di PHP è disattivo e non cancella in autonomia i files di sessione obsoleti.

Di conseguenza la tua cartella rischia di accumulare files senza limiti e questo alla lunga può darti problemi di vario tipo (performance, backup, esaurimento dello spazio etc)

20/05/2026 14:40:09

blancks ha scritto:

grazie per la dritta apro velocemente un ticket e vedo di sistemare intanto ho tamponato fortunatamente

20/05/2026 15:35:47

neworleans ha scritto:

grazie per la dritta apro velocemente un ticket e vedo di sistemare intanto ho tamponato fortunatamente

Grazie a te per la segnalazione e il modo in cui hai provvisoriamente risolto, è comunque utile per chiunque dovesse trovarsi con lo stesso problema (appena possibile la appendo come punto #6)!

Se possibile, tienici aggiornati per capire anche se il servizio clienti di Aruba è stato effettivamente risolutivo per il tuo caso

20/05/2026 18:47:45

blancks ha scritto:

Ben volentieri quando ho aggiornamenti vi faccio sapere.