Come faccio a esaminare e mantenere uno script di scheda immagine PHP con poca o nessuna esperienza nell'hosting di cpanel?

Elencati in ordine dalla maggior parte dei cowboy, spara-dai-anca, forse-questo-tutto-lavoro-ma-a-meno-provato modo di farlo fino al modo più controllato, orientato ai processi per fare in questo modo:

1. Ottieni un programma FTP, scarica i file che vuoi modificare, modificali con Notepad o Notepad ++ e usa FTP per caricarli di nuovo, controlla se la tua modifica ha funzionato.
2. Scopri che spingere le modifiche che non hai testato in un ambiente live è un po 'come guidare giù per l'autostrada con una benda. Usa Xampp o Wampp per configurare un server sul tuo computer locale. Scarica tutti i file dal sito Web e modificali, prova tutto in locale prima di capire cosa funziona, quindi individua esattamente quali file sono stati modificati e utilizza FTP per caricarli nuovamente. Trova un altro editor di testo.
3. Stancarsi di farlo, perché il tracciamento delle modifiche a mano è un PITA, e probabilmente significa che sovrascrivi il lavoro che hai perso l'ultima volta o finisci con conflitti tra il tuo lavoro e quelli di qualcun altro. Inoltre è super-noioso. Quindi impara abbastanza Git da essere spaventoso e crea un repository privato Github o Bitbucket. Modifica i file localmente, modifica le modifiche al tuo repository git. Impara un po 'su ssh, accedi al tuo server ed estrai i file git dal repository. Ricerca PHPStorm e decidi di fare il grande passo.
4. Si noti che a volte l'app si comporta in modo un po 'diverso perché è in esecuzione sul computer anziché sul server di produzione e in genere viene eseguita in "modalità di sviluppo" sul computer (il che rende più facile il debug delle nuove funzionalità) mentre è in esecuzione " modalità di produzione 'sul server principale. Decidi di creare un server di staging che assomigli e si comporti esattamente come il server di produzione, tranne che solo tu e i tester della tua azienda puoi accedervi. Distribuisci il codice usando lo stesso metodo di prima, tranne che ora puoi distribuire più spesso, perché il codice nell'ambiente di staging può essere testato da più persone, ma non è ancora pubblico.
5. Scopri che a volte stai ancora causando errori perché a volte le modifiche apportate in una parte del codice influiscono su altre cose che non hai realizzato. Impara un po 'di test e integrazione continua. Crea alcuni test di integrazione per assicurarti che alcune delle funzionalità principali funzionino. Collega il tuo repository git a un servizio di integrazione continua, quindi esegue la tua suite di test ogni volta che inserisci un nuovo codice nel repository.
6. Compilare la tua suite di test in modo che i casi e gli stati di errore nel codice siano inimmaginabili. Ci vorrà del tempo e non saprai davvero cosa testare all'inizio. Inizia a fidarti di esso. Collega il tuo servizio di integrazione continua al tuo server; configurarlo in modo che le modifiche apportate al ramo principale che superano tutti i test siano considerate pronte per la produzione e vengano distribuite automaticamente sul server.

Dal momento che per un noob completo questo probabilmente sembra assurdo, solo tu puoi decidere quale livello di processo richiede il tuo progetto. Inizia dove puoi e vai al livello in cui inizia a sembrare eccessivo. Fino a quando non lo fa.