OpenCart su PHP 8.
Negozio, tema ed estensioni.
Portiamo i negozi OpenCart 1.5 e 2.x sulle serie mantenute 3.0 e 4.1, con un inventario delle modifiche vQmod e OCMOD e una migrazione dei dati provata prima del passaggio.
Per e-commerce che girano da anni su versioni senza rilasci e su PHP 5 o 7, con decine di estensioni che modificano i file del core e rendono ogni aggiornamento imprevedibile.
Dal ramo che hai.
Al ramo supportato.
Le istruzioni ufficiali coprono il salto dalla 2.x alla 3.0 e gli aggiornamenti dentro la 4.1. Per un negozio su 1.5 o 2.x la strada più affidabile è di solito un’installazione pulita della serie di destinazione, con la migrazione dei dati.
- 01OpenCart 1.5.6.4PHP 5.x
Ultima della serie 1.5, estensioni basate su vQmod
- 02OpenCart 2.3.0.2PHP 5.4 o superiore
Ultima della serie 2.x, OCMOD entra nel core
- 03OpenCart 3.0.5.1PHP 8.1 o superiore
Serie mantenuta, vicina alla 2.x e con OCMOD funzionante
- 04OpenCart 4.1.0.4PHP 8.1 o superiore
Serie mantenuta, estensioni con namespace ed eventi
Versioni e PHP.
Ramo per ramo.
La versione minima di PHP è quella controllata dall’installer di ogni rilascio nel codice sorgente pubblicato da OpenCart.
Fonti: Repository ufficiale di OpenCart · Rilasci di OpenCart. La matrice dei rami di PHP con le distribuzioni Linux è nella pagina Versioni PHP.
Cosa blocca l’upgrade.
E come lo sblocchiamo.
In OpenCart il punto fragile sono le modifiche che cercano e sostituiscono testo nei file del core. Ogni cambio di versione le mette alla prova tutte insieme.
Modifiche vQmod e OCMOD
Una regola XML cerca una riga in un file del core e aggiunge codice prima o dopo. Quando la versione cambia la riga non si trova più e la modifica salta, a volte in silenzio. Le censiamo tutte e per ciascuna decidiamo se sostituirla, riscriverla o eliminarla.
Conflitti tra estensioni
Due modifiche che cercano la stessa riga entrano in conflitto, e l’ordine di applicazione decide il risultato. Con decine di file XML di fornitori diversi le proviamo una per una sulla versione di destinazione.
Codice scritto per PHP 5
Molte estensioni usano funzioni rimosse in PHP 7 e 8, come le vecchie mysql_* o each(). Vanno corrette in ogni caso, perché le serie mantenute richiedono almeno PHP 8.1.
Estensioni da riscrivere per la 4.x
Nella serie 4 ogni estensione vive in una cartella sotto extension/, con namespace e un pacchetto .ocmod.zip. Il codice per la 2.x o la 3.0 non si installa senza riscriverlo, e le modifiche XML diventano eventi.
File del core toccati a mano
Le modifiche fatte direttamente sui file originali non compaiono in nessun pannello. Le troviamo confrontando l’installazione con il pacchetto originale della stessa versione, e le riportiamo in estensioni.
Temi con logica dentro
Nella 1.5 e nella 2.x i temi in .tpl contengono spesso logica oltre alla grafica. Dalla 3.0 i template sono in Twig, quindi il tema si ricostruisce e la logica passa nei controller o nelle estensioni.
Il nostro intervento.
Passo dopo passo.
Se la migrazione richiede tempo, nel frattempo teniamo protetto il PHP in uso con il backport delle patch di sicurezza.
- 01INVENTARIO
Inventario e matrice
Copiamo file e database del negozio in un ambiente di prova ed elenchiamo estensioni, modifiche XML, file del core modificati e tema. Per ogni estensione verifichiamo se il fornitore offre la versione per la 3.0 o la 4.1.
- 02STAGING
Installazione pulita
Installiamo la serie scelta su PHP 8.1 o superiore e migriamo prodotti, categorie, clienti, ordini e pagine. Usiamo lo script ufficiale dove il salto è supportato e uno script dedicato negli altri casi.
- 03UPGRADE
Tema, estensioni e test
Ricostruiamo il tema e reinstalliamo le estensioni compatibili, poi proviamo percorso di acquisto, pagamenti, email e integrazioni con i dati reali. Gli URL che cambiano ricevono un reindirizzamento permanente.
- 04RILASCIO
Rilascio e ponte
Il passaggio avviene con Ansible, un breve blocco degli ordini e un piano di rollback. Se il negozio deve restare qualche mese sulla versione attuale, il backport delle patch di sicurezza protegge il PHP in uso.
Per approfondire.
OpenCart 1.5 e 2.x: aggiornare estensioni vQmod e OCMOD verso le versioni moderne
Come funzionano vQmod e OCMOD, perché le modifiche XML si rompono a ogni aggiornamento e come portare un negozio OpenCart 1.5 o 2.x verso le serie 3.0 e 4.1, che richiedono PHP 8.1, scegliendo tra modifiche OCMOD ed eventi.
Leggi l’approfondimentoE-commerce su PHP legacy: come migrare senza perdere ordini, clienti e posizionamento
Un metodo per migrare un negozio online da un PHP fuori supporto senza perdere lo storico degli ordini, gli account e le password dei clienti e le posizioni nei motori di ricerca: inventario, migrazioni di prova, congelamento breve, redirect 301 e monitoraggio.
Leggi l’approfondimentoDa PHP 5 a PHP 8: le funzioni rimosse che bloccano il tuo codice
Quali funzioni sono sparite in PHP 7.0 e in PHP 8.0, con cosa si sostituiscono, quali cambiamenti di comportamento rompono il codice senza errori evidenti e come fare l’inventario completo prima di iniziare la migrazione.
Leggi l’approfondimentoPrima di iniziare.
Le domande che ci fanno più spesso su OpenCart e PHP.
Meglio OpenCart 3.0 o 4.1?
La 3.0 è più vicina alla 2.x, mantiene OCMOD e ha molte estensioni commerciali disponibili, quindi è la scelta più rapida per chi ha molte estensioni. La 4.1 ha un sistema di estensioni più pulito ma chiede di riscrivere quasi tutto il codice aggiuntivo. Per un negozio che deve durare anni partire dalla 4.1 evita un secondo grande salto.
Esiste un aggiornamento automatico dalla 1.5?
Il file UPGRADE.md della serie 3.0 descrive l’aggiornamento dalla 2.x e per la 1.5 rimanda al supporto a pagamento del progetto. Quello della 4.1.0.4 copre solo gli aggiornamenti dalle versioni 4.1.0.x precedenti. Per questo dalla 1.5 lavoriamo con un’installazione pulita e una migrazione dei dati.
Le modifiche vQmod funzionano su OpenCart 3.0?
Vanno convertite in OCMOD, che ha una sintassi vicina, e adattate al nuovo codice del core. Dalla 2.x i controller scrivono in $data invece che in $this->data, ed è proprio questo tipo di differenza a rompere le regole di ricerca.
Clienti e ordini restano dopo la migrazione?
Sì, prodotti, clienti e ordini fanno parte della migrazione dei dati e vengono controllati nell’ambiente di prova prima del passaggio. Il blocco degli ordini serve solo durante l’ultima importazione, per non perdere acquisti fatti nel frattempo.
Aggiorniamo
il tuo negozio.
Indicaci versione della piattaforma, versione di PHP e sistema operativo. Ti risponderemo con una prima valutazione del percorso di upgrade e di cosa serve per arrivarci.
Richiedi una valutazioneLunedì – venerdì · 09:30 – 19:30
+39 340 985 4556 ↗