Errore dopo aggiornamento a OSM 2.9.8

buldo

Buonasera a tutti,

stamattina ho deciso di aggiornare la versione 2.7.2 in uso e purtroppo mi sono imbattuto in errori multipli, ho quindi ripristinato il backup e aggiornato a versioni intermedie (2.8.1, 2.8.3 e poi 2.9.8), cercando soluzioni ai problemi già noti qui sul form e in rete.
Ho anche fatto un'installazione pulita dei file, eliminando tutto e ricreando il file di configurazione da zero sempre puntando lo stesso DB con i dati di produzione e alla fine sono riuscito ad ottenere una versione aggiornata con diversi warning e qualche errore, nello specifico riporto questi:

Dettagli tecnici dell'errore:
Messaggio: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'is_bloccato' in 'where clause'
File: /home/src/Database.php
Linea: 288

Dettagli tecnici dell'errore:
Messaggio: array_key_exists(): Argument #2 ($array) must be of type array, null given
File: /home/modules/aggiornamenti/src/Utils.php
Linea: 137

Informazioni di sistema:
Versione PHP: 8.3.28
Sistema operativo: Linux 4.18.0-553.89.1.el8_10.x86_64 #1 SMP Mon Dec 8 03:53:08 EST 2025 x86_64
Browser: Google Chrome
Versione OpenSTAManager: 2.9.8

oltre a questi warning

Se sono utili altri dettagli ditemi pure così provvedo a recuperare le informazioni necessarie.

Ringrazio sin da ora chi può aiutarmi a capire come risolvere e auguro a tutti buone feste.

Saluti,
Andrea

sajo

buldo

ci sta il consiglio di carlopellizzato 👍
anche noi di norma facciamo cosi, prima su installazione pulita e poi in produzione.

comunque di base non è necessario fare fare un agg. alla volta, perchè l'ultimo ha anche gli agg. intermedi
quando si presenta un errore, è sufficiente commentare script che da errore e forza l'agg. così procede con l'agg. e arriva all'ultima versione
poi ti basterà correggere sul DB, che di solito sono 2-3 errori
tra altro nelle ultime versioni è stato introdotto e migliorato anche la modalità di correzione automatica direttamente da OSM 👍

carlopellizzato

Ciao, non ho la soluzione al problema, ma un suggerimento.
Meglio evitare aggiornamenti su salti di versioni così importanti. Io utilizzo un ambiene di test e man mano arrivano nuove versioni le applico prima il e vedo come si comporta. Solo risolti i problemi li applico alla versione in produzione.
Alcune volte ho dovuto attendere una o anche 2 relase successive prima di applicarle.
Dalla 2.7.2 ne ho fatte di correzzioni (su indicazione) per risolvere vari problemi più o meno gravi presentatisi, mi verrebbe mal di pancia all'idea di passare dalla 2.7.2 in un colpo solo, ma anche dalla 2.8.3. Hanno fatto modifiche abbastanza strutturali, dai db, a moduli etc.
Comunque un sentito grazie agli sviluppatori che hanno creato un prodotto molto valido!
E buon natale a tutti!

buldo

carlopellizzato grazie del suggerimento, è una pratica che ho seguito fino a qualche tempo fa e l'ho abbandonata perché non riesco più a dedicare il tempo necessario.
Comprendo il "rischio" del salto di versione, tuttavia la procedura di aggiornamento è costruita in modo da adeguare il DB rispettando gli avanzamenti tra la versione attuale e quella successiva e penso che nel mio caso più di qualcosa deve essere andato storto negli aggiornamenti precedenti (avevo già scritto qui sul forum in passato per le stesse problematiche).
Se fosse possibile "esportare" i dati e reimporarli su un'installazione pulita magari si riallinea tutto, finora aggiornando lo stesso DB la situazione resta sempre "instabile".

Oltretutto le uniche personalizzazioni "reali" che ho fatto, modificando i file e non il DB, sono il testo nel footer, il percorso e il nome dei backup, oltre a sostituire il logo per riconoscere l'installazione in uso, quindi lato DB mi aspetterei una situazione "normale" e non certo quelle "tabelle non previste" o "viste personalizzate" a cui non ho mai messo mano.

buldo

sajo anche noi di norma facciamo cosi, prima su installazione pulita e poi in produzione.

Se usi un'installazione pulita è molto probabile che non ci saranno problemi durante l'aggiornamento, bisognerebbe clonare la produzione in uso e testarlo su quella.

sajo poi ti basterà correggere sul DB, che di solito sono 2-3 errori

Quindi dovrei eliminare tranquillamente le "7 tabelle non previste" e adeguare a mano le "66 viste personalizzate"?

sajo

buldo Se usi un'installazione pulita è molto probabile che non ci saranno problemi durante l'aggiornamento, bisognerebbe clonare la produzione in uso e testarlo su quella.

no no si presentano problemi anche su OSM pulito, dipende dal tipo di agg.

buldo Quindi dovrei eliminare tranquillamente le "7 tabelle non previste" e adeguare a mano le "66 viste personalizzate"?

per l'automatismo introdotto di recente mi riferisco nello specifico al Controllo del database nei controlli dii integrità 👍
invece per le Personalizzazioni Rilevate vanno corrette su OSM o sul DB dipende da cosa sono e così al prossimo agg. sarai apposto

un consiglio che viene spesso indicato è quello di avere una installazione apposto prima di procedere con aggiornamenti

buldo

sajo un consiglio che viene spesso indicato è quello di avere una installazione apposto prima di procedere con aggiornamenti

Al di là delle 3 modifiche ai file, non risultavano altre segnalazioni, rispetto al DB purtroppo temo che siano "residui" delle versioni più vecchie che mi sto portando dietro e concordo vanno sanate, la mia difficoltà è sapere come 😅 proverò a seguire le indicazioni che ci sono, intanto grazie del suggerimento.

sajo un problema che ci capita spesso, e che durante un agg. alcuni file non vengono sovrascritti

Per questo motivo ho cancellato tutto sul server e decompresso il file della nuova versione apportando nuovamente le modifiche ai file post aggiornamento.

Aggiungo che ho dovuto eliminare la riga 290 dal file "include/top.php" perché generava un errore bloccante:

AISystemPrompt: "'.addslashes(setting('Prompt di sistema per Modello AI')).'",

E' accaduto a qualcun'altro?

sajo

un problema che ci capita spesso, e che durante un agg. alcuni file non vengono sovrascritti
per fare un check usiamo un programma ( Beyond Compare ) che confronta la cartella contenente l'agg. es 2.9.8 e la cartella dove c'è il programma appena aggiornato

vedi Anomalia agg. osm #1621

buldo

Indagando sullo "Stato dei servizi" sono parecchi quelli che risultano fermi alla 2.7.3, mi sa che devo ripristinare il backup ante aggiornamento e ritentare.

buldo

Penso di aver risolto:

ho ripristinato il backup pre aggiornamento, quindi la versione 2.7.2, sia file che DB;
ho avviato l'aggiornamento 2.9.8 che è stato eseguito senza intoppi particolari;
mentre verificavo le varie impostazioni ho ricevuto errore 500, quindi ho eliminato tutti i file dal server;
ho decompresso il file contenente la versione 2.9.8 sul server e aggiornato la pagina;
si è avviato il wizard per la nuova installazione ed ho indicato i dati del DB "vecchio" confermando l'avvio della procedura;
sono partiti TUTTI gli aggiornamenti previsti per il DB dalla versione 2.7.2 alla 2.9.8;
ho modificato i 2 file (forse il percorso del backup posso impostarlo dalla configurazione adesso).

Ho seguito anche le indicazioni riportate qui.

Ora vorrei risolvere questi altri punti in sospeso:

Per ora mi accontento, mi sono fatto un bel regalino di Natale 😃