Buon dì, ho ritrovato il post (https://helpcenter.websitex5.com/pt/post/201369#comment_201369_18), ma non il codice riferito.

Se Giorgio C.ha la possibilità di postare nuovamente il progetto elaborato, per dividere i dati aggiunti su un'altra tabella senza sporcare quella creata dal programma ne sarei molto felice.

Ciao Gabriele, 

di regola il software rimuove i dati da quella tabella solo se gli utenti vengono eliminati nel software: È possibile che sia attivo uno script che possa avere svuotato la tabella?

Grazie! Buona giornata.

@Gabriele ... impiega un po' , non so se è colpa dell'host altervista o se del codice che ho usato... un minutino a girare, ma mi pare funzioni anche se da perfezionare (non ho provato con la tabella che dici tu ma con un altra ...)

comunque ho fatto così

una pagina per duplicare una-tantum la struttura della tabella con

- collegamento al DB

poi istruzione sql:  CREATE TABLE tabella_copia LIKE tabella

altra pagina per fare la copia dei dati con

- collegamento al DB

poi istruzione sql: insert into tabella_copia select * from tabella

se hai dei dubbi scrivimi... la mia mail dovresti già averla... 

Ciao Elisa,

il problema mi è capitato anche in una seconda circostanza, proprio in concomitanza dell'inoltro del progetto allo Staff. Qualche anno fa.

In genere quando devo inoltrare il progetto, duplico la cartella dal software, rimuovo i dati che ritengo sensibili, (come gli utenti) e modifico le credenziali nello Step 5 (se non serve un intervento sul server). Il tutto senza sincronizzare nulla online. Alla fine esporto il file .iwzip e lo inoltro. Ma come detto duplicando prima il progetto per non interferire.

Da logica, se duplico il progetto e non sincronizzo i dati online non dovrei riscontrare questo difetto. Ma nonostante ciò il problema si palesa.

È come se mi fosse stato fatto un DROP della tabella. 

Comprenderai che il danno per un sito come gebher.com, in fase di costruzione, è di poco conto. Tuttavia quando il problema si presenta su siti attivi la faccenda varia notevolmente.

No, per essere onesto non ho ancora implementato nessuno script adibito a eliminare. Attualmente ho solo funzioni per la modifica dei dati (SELECT FROM e INSERT INTO), che tuttavia agiscono in modo mirato in quanto vanno a modificare solo i dati collegati all'utente loggato (WHERE). Me ne sarei accordo essendo che sono mesi che i codici sono attivi e tendenzialmente a ogni riga modificata faccio dei test.

Se male implementati tutto al più sovrascrivono l'intera tabella, ma non eliminano come un TRUNCATE/DROP i record.

Certamente ci sono i backup, ma almeno per il mio hosting non è mirato alla singola tabella, dunque mi porta inevitabilmente a perdere altri dati.

In aggiunta ho notato un secondo problema, ma non comprendo se sia collegato alla nuova versione e contemporaneamente a questo esporto in questo post, sempre sulla tabella che WebSite X5 Pro usa per gli utenti online.

Premettendo che sono solito sperimentare funzioni personali con il database, come nei post molto letti (Rif.to https://helpcenter.websitex5.com/pt/post/201369), con conseguente alterazione della tabella usata da WebSite X5 Pro (Gestione Utenti), perché molto banalmente è più facile agire su una tabella già creata ma sopratutto già popolata.

Ho riscontrato, con l'aggiornamento alla versione Beta attuale ma in modo generico alla nuova versione 2022.3 che gli utenti non riescono a registrarsi automaticamente online. Quelli già registrati possono accedere senza problemi, tuttavia un nuovo utente riceve errore.

Inizialmente ho imputato il problema al PHP (che di  fatto era in essere) ma una volta ovviato, la persistenza del problema mi ha fatto uscire matto. Per puro caso, il programma ha fatto il DROP della tabella, reimpostando le celle a quelle originali e  ho compreso che il bug di accesso era dato dalla tabella che presentava colonne extra (note, telefono etc.).

A parte il DROP abbastanza strano, ti domando se è normale un bug simile.

Ovviamente mi assumo la responsabilità essendo che una tabella del software alterata non è prevedibile dalle logiche del software. Tuttavia sono curioso, perché è un comportamento nuovo, e come sai i bug mi intrigano.

Buonasera Claudio! Grazie per il gradito riscontro. Non ricordo di avere la tua e-mail ma controllo nella rubrica. Nel caso se hai piacere puoi scrivere a gabriele.c(@)stiac.it . Ovviamente non mi permetto nel fare spam.

Mi piacerebbe dare uno sguardo al codice che hai strutturato.

Attualmente sono riuscito a creare solo soletto uno script dedicato, dopo aver provato senza successo a tanta rabbia, un supporto su stackoverflow. Non puoi comprende che antipatia gira in quella community.

La logica parte dal controllare se la tabella esiste con un if (empty($result)) per poi generarla da zero se inesistente con CREATE TABLE IF NOT EXISTS, per poi proseguire con un secondo controllo per accertare se l'id utente (email) è presente nella tabella. Se non presente importa i dati dalla tabella che usa il sito con un INSERT INTO. La pecca del mio script è che fa il "salvataggio" solo dell'utente che ha avuto iterazioni con le pagine, ergo naviga dove è messo lo script, però pare abbastanza veloce, tutto in una singola pagina richiamato con un require_once.

Ho messo un prova online (https://www.gebher.com/create_database9.php) ma è ancora un lavoro in corso essendo che l'ho buttato giù in macchina oggi. 

Alla prima visita vedi molti avvisi PHP ma è normale perché sono abilitati in quella pagina, alla seconda ti mostra l'echo riferito alla creazione tabella e salvataggio ID. Per comodità ho messo anche gli echo dei dati utente così da poter verificare meglio:

E.s.

come detto è da perfezionare , ma ho messo solo quello che ho scritto prima... senza nessun controllo

ed io farei fare il salvataggio ogni tanto , non di continuo ad ogni accesso, non ne vedrei la necessità... anzi lo vedrei come un sovraccarico di lavoro

Buon dì, ho trovato la tua e-mail!

Il salvataggio avviene solo una volta per utente, così come la creazione della tabella. Salva solo ed esclusivamente se non trova l'email loggata.

Non so se il controllo possa gravare alla lunga sul tempo di caricamento. Rendendolo arbitrario all'utente mi sgrava a me l'onere di eseguirlo con cadenza, e dall'altra parte rende utilizzabile il codice per la strutturazione del profilo utente, perché oltre al backup dei dati mi inserisce di fatto l'email utente in una tab non usata dal programma.

Mi sarebbe piaciuto poter visionare la bozza di Giorgio che citava, per poter strutturare una versione "aggiornata" per la versione 2022.3.

Comunque sia, vediamo che dice la nostra Elisa circa i bug segnalati.

Ciao Gabriele,

da cosa dici sembra che duplichi il progetto senza utenti, così da potercelo passare, e che esportandolo i dati vengano eliminati: quando invece usi normalmente il software questo non avviene, corretto?

Grazie!

Forse mi sono mal spiegato. Generalmente quando il buon Stefano mi chiede il progetto, apro il programma e dalla finestra (allegata) duplico il progetto.

SOLO sul progetto duplicato, mi reco generalmente in Gestione Accessi e Step 5 per rimuovere i dati.

Dallo Step 5 esporto il progetto DUPLICATO con nome differente (es. nomeprog_incomedia.iwzip) e lo invio.

Terminata questa fase di "INOLTRO" chiudo il progetto duplicato e ritorno a lavorare sul progetto originale.

Usando normalmente il progetto cerco di evitare di entrare in Gestione Accessi, e ovviamente non rimuovo gli utenti. Però ti confermo che di norma non mi capita tale problema. Altrimenti me ne sarei accorto.

Da mia memoria, si è verificato solo una seconda volta, qualche anno fa come citato in precedenza, sempre per la medesima circostanza.

Ciao Gabriele, 

abbiamo provato a seguire anche noi questa procedura con un progetto di test ma non abbiamo riscontrato lo stesso problema, magari non facciamo proprio la stessa cosa: mi mandi degli screenshot per farmi vedere passo per passo quello che fai per favore?

Grazie! 

Certamente, come ho del tempo posto per commento singolo tutte le operazioni descritte in precedenza.

Grazie per il supporto.