[GDRCD] Possibili problematiche passando a nuovo hosting

20/05/2026 21:56:28 e modificato da blancks il 20/05/2026 21:59:32

demonhantagdr ha scritto: ...

Credo di aver individuato il problema che stai riscontrando in gestione luoghi e 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 ottieni 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ò essere sorto su aruba perché magari le configurazioni del database mysql sono più stringenti rispetto a quelle di altervista.

Quando riesci, fammi sapere se questo suggerimento risolve effettivamente il problema 🤞

20/05/2026 22:29:32 e modificato da blancks il 20/05/2026 22:30:16

neworleans ha scritto:

Ben volentieri quando ho aggiornamenti vi faccio sapere.

Grazie! Nel frattempo ho aggiunto la tua segnalazione come punto #6 nel post di inizio thread.

Ti consiglio di seguire il passaggio in merito alla creazione del file .htaccess che ho inserito 😉

20/05/2026 22:33:53 e modificato da demonhantagdr il 20/05/2026 22:34:15

Ciau Blancks e grazie anche a udgdr per i preziosi consigli! :)
Vi condivido cosa sono riuscita a fare, seguendo un po' i ragionamenti di tutti e due.

Il problema dipende da come viene formattata il campo scadenza di tipo datetime. Nella query di insert e di update viene valorizzato nel seguente modo

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

Quando i valori in post non sono valorizzati viene impostato zero di default e la stringa risultante è la seguente:

0-0-0 00:00:00.

Dato che la colonna è un datetime il valore corretto dovrebbe essere

1099-01-01 00:00:00

Io non uso questo campo perchè serve per le chat private. Nel mio caso ho modificato la query in modo da inserire null. Andrebbe inserito un controllo su $_POST['year'] $_POST['month'] $_POST['day']) in modo da inserire null solo quando non sono valorizzati. Nel caso in cui fossero valorizzati va controllato che il formato della stringa risultante sia coerente con il formato previsto dal datetime che dovrebbe essere yyyy-MM-dd HH:MM:SS

Praticamente così facendo mi funziona sia sulle vecchie chat che sulle nuove e ho risolto! :) Blanks il tuo post è veramente UTILISSIMO!! GRAZIE, speriamo di esservi stati utili anche noi, ragazzi! :)

20/05/2026 22:55:15

demonhantagdr ha scritto: Praticamente così facendo mi funziona sia sulle vecchie chat che sulle nuove e ho risolto! :) Blanks il tuo post è veramente UTILISSIMO!! GRAZIE, speriamo di esservi stati utili anche noi, ragazzi! :)

Ottimo e grazie a te per aver segnalato il problema, sarà sicuramente d'aiuto anche per altre persone!

21/05/2026 00:39:32

blancks ha scritto:

Grazie! Nel frattempo ho aggiunto la tua segnalazione come punto #6 nel post di inizio thread.

Ti consiglio di seguire il passaggio in merito alla creazione del file .htaccess che ho inserito 😉

Cacchien vero mi ero scordato .htaccess risolto al volo grazie del remind, sono ancora piuttosto babbo XD non lo nego.

22/05/2026 09:01:54

Aruba mi ha risposto vi copio la risposta. In pratica non toccano nulla, adesso provvederò a inserire una pulizia automatica e pazienza

Gentile Cliente,

si conferma che su hosting condiviso di Aruba S.p.A. le impostazioni lato server non sono personalizzabili liberamente, salvo alcune specifiche direttive PHP consentite dall’ambiente hosting. Questo perché la configurazione del server è condivisa tra più siti presenti sulla stessa macchina e modifiche ai parametri globali delle sessioni avrebbero effetto su tutti gli account ospitati.

Per tale motivo non è possibile intervenire direttamente sulla gestione della directory /tmp di sistema o sulle policy globali di pulizia delle sessioni.

La soluzione adottata tramite:

session_save_path('/web/htdocs/www.tuosito.it/home/includes/sessions');
session_start();
risulta corretta e rappresenta l’approccio consigliato in ambiente shared hosting, in quanto consente di utilizzare una directory dedicata al sito evitando la cancellazione automatica dei file presenti nella /tmp condivisa.

Si consiglia tuttavia di prevedere una pulizia automatica periodica della cartella delle sessioni, ad esempio tramite cron job schedulato e codcie php , così da evitare l’accumulo progressivo dei file nel tempo.

In questo modo sarà possibile mantenere stabile la gestione delle sessioni senza impatti dovuti alla pulizia automatica della /tmp di sistema.

22/05/2026 09:15:47 e modificato da moderazione il 28/05/2026 16:15:13

Aggiungo per spiegare come ho inserito la pulizia automatica, sperando di aver fatto tutto corretto.

ho modificato il required (la cartella includes/sessions l'avevo già creata in precedenza)

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

// Durata massima sessione inattiva (24 ore)
ini_set('session.gc_maxlifetime', 86400);

// Cookie sessione valido 24 ore
session_set_cookie_params([
'lifetime' => 86400,
'path' => '/',
'httponly' => true,
'samesite' => 'Lax'
]);

// Avvio sessione
session_start();

e sotto tutti gli altri includes in pratica ho cambiato la stringa precedente di inclusione con questa più evoluta ragionata per la pulizia.

poi ho creato il file includes/cleanup_sessions.php

<?php

$sessionPath = '/web/htdocs/www.tuosito.it/home/includes/sessions';

$maxLifetime = 86400; // 24 ore

if (!is_dir($sessionPath)) {
exit;
}

foreach (glob($sessionPath . '/sess_*') as $file) {

if (!is_file($file)) {
continue;
}

if ((time() - filemtime($file)) > $maxLifetime) {
unlink($file);
}
}

Poi va modificato il permesso cron in pannello altervista.
PRIMA ho verificato che il clean funzionasse

https://www.tuosito.it/includes/cleanup_sessions.php

aprendolo se non da errore ma pagina bianca dovrebbe funzionare a dovere.

a questo punto son andato sul pannello di aruba
Hosting Linux
Processi Cron
Aggiungi Cron
Comando /usr/bin/php /web/htdocs/www.tuosito.it/home/includes/cleanup_sessions.php
per ora ho settato ogni 24 ore la pulizia una volta al giorno

Dovrebbe essere tutto per rendere la patch del "sessione scaduta" ottimizzata e definitiva, senza appesantire di salvataggi. La testo stanotte a mezzanotte farà la pulizia e verifico sia andato tutto ok.

22/05/2026 10:19:55 e modificato da blancks il 22/05/2026 14:03:13

neworleans ha scritto: Aruba mi ha risposto vi copio la risposta. In pratica non toccano nulla, adesso provvederò a inserire una pulizia automatica e pazienza

Cancellare le sessioni attive per una procedura di pulizia non è un operazione normale, ma il loro punto di vista in breve è "siccome ormai abbiamo tanti utenti in shared su quel server, preferiamo non toccare nulla altrimenti scombiniamo le cose a chi si era già adattato".

Capisco il punto, ma non condivido il dover far adeguare i propri clienti in shared hosting ad una configurazione poco accorta lato loro. But I digress.

La tua soluzione dovrebbe funzionare, ma ti suggerisco alcune accortezze.

Questo puoi rimuoverlo:

// Durata massima sessione inattiva (24 ore)
ini_set('session.gc_maxlifetime', 86400);

Definisce una configurazione del garbage collector (gc) per i files delle sessioni. Il servizio clienti ti ha risposto di dover creare un tuo script per la pulizia, significa che quella nativa di PHP (il gc appunto) non è in funzione, pertanto questa configurazione non fa all'atto pratico nulla nel tuo caso.

// Cookie sessione valido 24 ore
session_set_cookie_params([
'lifetime' => 86400,
'path' => '/',
'httponly' => true,
'samesite' => 'Lax',
'secure' => filter_var($_SERVER['HTTPS'] ?? '', FILTER_VALIDATE_BOOL), // aggiungi questo
]);

Questa è un ottima aggiunta a prescindere, in particolare per httponly e samesite. Visto che ci sei e che il tuo sito mi sembra sotto https, ti suggerisco anche il parametro secure per completare le configurazioni di sicurezza.

neworleans ha scritto: poi ho creato il file includes/cleanup_sessions.php

Il file che hai creato funziona e probabilmente è più che sufficiente.
Mi sono permesso comunque di rivederlo un attimino perchè l'uso del glob in questo contesto non mi piace particolarmente.

glob carica in memoria nello script l'intera lista dei files di sessione.
se ti prende di mira un bot che te ne fa generare tanti prima della cancellazione o se per qualche motivo di problematiche lato aruba il job dovesse fermarsi e ripartire improvvisamente molto tempo dopo, lo script potrebbe bloccarsi in corrispondenza di quell'istruzione esaurendo la memoria a disposizione dello script php.

L'evento è raro, ma preferisco fornire una mia versione che, invece di caricare tutta la lista dei files nella memoria dello script, li carica progressivamente. In questo modo il job non avrà difficoltà a gestire le casistiche che ho indicato in caso di imprevisti.

Ho anche cambiato le variabili di configurazione ad inizio script così che sia più semplice configurarle:

<?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);
}

Se provi il mio script, fammi sapere se funziona correttamente 😉

22/05/2026 10:24:59

ogni correzione ben accetta, son uno smanettone non di certo un programmatore e aspesso mi adopero con soluzioni creative per risolverla (e dopo sei mesi mi guardo indietro e mi vergogno di alcune soluzioni adottate e le cambio) inserito, il codice e le tue modifiche, sembra stabile a mezzanotte facciamo il test definitivo quando il clean si attiverà e vediamo s ef atutto come deve senza far crollare nulla.

grazie come sempre!

22/05/2026 10:29:33 e modificato da blancks il 22/05/2026 11:19:26

neworleans ha scritto: ogni correzione ben accetta, son uno smanettone non di certo un programmatore e aspesso mi adopero con soluzioni creative per risolverla (e dopo sei mesi mi guardo indietro e mi vergogno di alcune soluzioni adottate e le cambio) inserito, il codice e le tue modifiche, sembra stabile a mezzanotte facciamo il test definitivo quando il clean si attiverà e vediamo s ef atutto come deve senza far crollare nulla.

grazie come sempre!

Grazie a te! Ho fatto due piccole correzioni in giro di cui mi sono accorto dopo aver riletto (sorry), in caso ricontrolla se tutto corrisponde