Inizializzazione tabella nel database per la registrazione automatica degli utenti 
Autore: Serzio ©Una cosa che continua a non piacermi.
Ho appena creato da zero un piccolo esempio di sito web con la versione 13pro per la registrazione automatica degli utenti. Nella finestra della "gestione accessi", pannello "utenti", vi è la possibilità di aggiungere (o rimuovere) utenti "statici" (per così dire ... direttamente da parte dell'amministratore) che, con l'esportazione, andranno a finire nel file /res/access.inc.php anche se viene selezionato il metodo di registrazione automatica su database.
Capisco che si tratta di due cose "letteralmente" diverse ... utenti con "accesso privilegiato" e utenti con "registrazione automatica" .... però .... in questa maniera, a parte il discorso di intuitività nella gestione dell'intero insieme di utenti, si hanno due meccanismi diversi per la gestione degli utenti. Non sarebbe stato meglio far convogliare tutto all'interno di un unico database?
Inoltre, anche con l'esportazione del sito, la tabella designata per la registrazione automatica non viene creata fin da subito, ma al momento della registrazione del primo utente.
Altro punto che non mi piace. Ho provato ad eseguire la registrazione di un utente senza procedere alla verifica dell'account. Un attimo dopo ho provato ad inserire lo stesso utente staticamente da website, ma senza aver aggiornato preventivamente la tabella ed ho esportato il sito. Al successivo tentativo di accesso con i dati dell'utente neoregistrato, non è possibile eseguire il login ne con la password impostata durante la registrazione automatica (non ho eseguito la verifica dell'account) ne con quella dell'inserimento statico. L'utente non mi risulta più utilizzabile con nessuna delle due password anche se effettuo la verifica dell'account.
Autore
Ho resettato tutto. Eseguito la procedura di dopia creazione dello stesso utente con sequenza diversa ed ho ottenuto che lo stesso utente adesso entra con entrambe le password. Il risultato è che la situazione di doppia modalità di ingresso persiste fino a quando viene eseguita la procedura di aggiornamento in website e risolta manualmente dall'amministrazione.
La gestione degli accessi mediante due strumenti diversi contemporaneamente è inefficiente.
Questo è quanto. Buona notte a tutti e sogni ... in php.
http://www.unofficialwsx5.com
Autore
A questo punto, siccome non volevo perdere i dati inseriti dall'utente mediante la procedura di registrazione automatica, ho messo le mani sul db per modificare a mano il nome inserito per il "login". Pertanto la situazione di errore è stata rimossa manualmente mediante phpMyAdmin, ho pensato. Adesso non mi resta che aggiornare le tabelle degli utenti da website per aver risolto il problema senza perdere nessuno dei dati inseriti in maniera conflittuale.
Ed invece, l'aggiornamento non aggiorna più nulla ed il conflitto persiste. La procedura di website sembra essersi bloccata e mi costringe alla modifica dell'utente inserito staticamente o alla rimozione di quello dinamico. Il tutto pur consentendo l'ingresso ad entrambi gli account .. anche quello con i dati modificati tramite phpMyAdmin. Da notare che anche dopo aver rimosso l'errore ... la procedura di aggiornamento di website non è in grado di re-importare la modifica effettuata direttamente sul db.
http://www.unofficialwsx5.com
Buongiorno Serzio,
il procedimento di salvataggio sia su file che nel db è corretto perchè si deve garantirne il funzionamento sia sulla evo che sulla pro (sulla evo la gestione dei database non c'è).
E' corretto che la tabella non venga creata fino al primo utente, WebSite X5 funziona così e fino alla prima iscrizione non viene creato nulla.
Se si aggiorna la lista comparirà un avviso che i due utenti vanno in conflitto, questo è corretto perchè esistono due utenti uguali ed è corretto che l'utente non possa accedere perchè è ancora da validare. Se ti appare l'avviso di conflitto, va risolto in WebSite X5 non modificando il db, occorre quindi modificare l'utente solo con gli strumenti forniti da WebSite X5 e non agendo manualmente sul database.
Grazie per la precisazione, valuteremo di migliorare questo processo se non è intuitivo come hai descritto.
Grazie.