L’assistenza al sito è sempre essenziale

Abbiamo parlato dell’acquisto di un sito internet nel 2023 e di cosa aspettarsi a seconda del budget stanziato. Abbiamo parlato del perché la SEO non è accessoria ad un sito internet, ma semmai fondamentale. Dobbiamo parlare di un altro servizio essenziale per un sito internet e che spesso viene trascurato o ignorato in sede di preventivo; se proprio vogliamo dirla tutta, certi clienti furbacchioni sperano di ottenere gratuitamente questo servizio, che potrebbe rivelarsi la parte più sostanziosa della lavorazione: parliamo dell’assistenza al CMS. Soprattutto con i clienti di cui sopra, che cercheranno di essere quanto meno chiari possibile durante gli incontri preliminari all’offerta nella speranza che diverse “piccole” situazioni non ponderate (che inevitabilmente si presenteranno) possano cadere in cavalleria. Dall’altra parte, se dovesse capitare alla web agency o al freelance con il fatturato in flessione e quindi impossibilitato a rifiutare commesse, potrebbe chiudersi un accordo non degnamente definito, con un sacco di post-vendita e situazioni in cui il cliente con richieste al limite dell’abusivo vada a spingere per il trattamento di favore.

Situazioni che sono capitate a qualsiasi web agency, alcune volte anche con clienti al di sopra di ogni sospetto (finanziariamente parlando); ma al di fuori dei casi limite e di chi parte in mala fede, anche chi è al di fuori del settore spesso ignora l’importanza dell’assistenza; per questo dobbiamo necessariamente spiegare cosa comporta e dove vanno quei soldi in più che le web agencies vi chiedono.

Per cominciare, la stragrande maggioranza dei progetti per un sito web sono basati su WordPress; per ora togliamo dalla menzione gli e-commerce con Prestashop e Magento2 (quest’ultimo ormai noto come Adobe Commerce) e i siti istituzionali basati su Joomla!, ci torneremo. Ovviamente ci sono anche siti costruiti con CMS o piattaforme inferiori a WordPress, e quindi meno professionali, e ci sono anche progetti più ambiziosi basati su framework personalizzati e/o dedicati; in quest’ultimo caso il cliente ottiene solo gli aggiornamenti di sicurezza necessari che vengono rilasciati dalla software house e dai quali non può esimersi; li paga cari ma non è un problema, stiamo proprio parlando di un altro livello di commessa. Se invece il cliente ha scelto Squarespace o altri CMS/servizi meno professionali rispetto a WordPress, con ogni probabilità avrà minime, per non dire inesistenti, possibilità di personalizzazione, di scalabilità, di implementazione di funzioni. Questi progetti sono spesso figli del fai da te o dell’intervento dei fantomatici “cugini”, e la maggior parte delle volte il cliente contatta parlando di un restyling, rinnovamento del sito, quando è senz’altro più proprio parlare di un progetto ex-novo.
Abbiamo parlato anche degli e-commerce come Prestashop e Magento2 e di Joomla!. È necessario fornire qualche dettaglio in più sulle piattaforme, darvi gli elementi per poter comprendere le sfumature sul servizio di assistenza. Cominciando da Joomla!, se nelle prime release si attestava come un effettivo rivale di WordPress, andando avanti con lo sviluppo ha avuto la peggio in termini di versatilità, per via sicuramente di una community ridotta e quindi di un più povero parco estensioni, che di conseguenza ne limitano la destinazione di utilizzo, perlomeno in Italia, ai contesti istituzionali. Continua ovviamente ad essere aggiornato per mantenere gli standard di sicurezza, ma non con la frequenza con cui gli aggiornamenti vengono rilasciati su WordPress, e dato che i possessori di un sito basato su Joomla! sono per la maggior parte enti o pubbliche amministrazioni, accettano spesso di buon grado di spendere il necessario per l’assistenza, ovvero per tenere sempre nella massima efficienza la piattaforma.

Più problemi e più soluzioni

Parlando di Prestashop e di Magento2, stiamo invece parlando di CMS pensati esclusivamente per ospitare un e-commerce. Nella fattispecie, possiamo considerare Prestashop la scelta intermedia in termini di complessità progettuale, dove Woo-Commerce (l’e-commerce basato su WordPress) è la scelta dei principianti con deboli ambizioni, e Magento2 si associa invece ai progetti più ambiziosi e viene acquistato, salvo eccezioni, da aziende strutturate e capaci di investire cifre importanti. Nonostante questa premessa, è possibile trovare aziende che all’acquisto del sito non intendano sottoscrivere un piano di assistenza. E soprattutto in questo caso ne derivano complicazioni. Perché tutto il paradigma della stabilità dell’ambiente software (finché si rimane nei termini di soluzioni open source, come quelle già menzionate) si basa su questa premessa: più è semplice da sviluppare, maggiore sarà la community di sviluppatori in appoggio; più è semplice da sviluppare, maggiori saranno i rischi di nuove vulnerabilità alla sicurezza, ma altrettanto tempestive le soluzioni; e ancora, più grande sarà la community e più grande sarà la scelta nelle integrazioni di nuove funzionalità.

Ora consideriamo un progetto tipico con WordPress. Ci sarà un tema installato con, probabilmente, un motore grafico (Elementor, Bakery o simili). Ci sarà un plugin per la gestione dei cookies come da GDPR. Questo per rimanere leggeri. Ma probabilmente ci sarà un plugin per la gestione dei form di contatto, probabilmente ci sarà Yoast per la SEO e ci sarà Wordfence. E questo ignorando ogni possibile altra esigenza progettuale. Ognuno di questi plugin riceve degli aggiornamenti per restare sicuro, correggere i bug e implementare nuove funzionalità (o gestire meglio quelle vecchie), o più spesso per rientrare in compatibilità con WordPress o con il rilascio di una nuova versione di PHP. PHP è il linguaggio principale su cui è basato il CMS WordPress e coinvolge pesantemente anche gli altri CMS più diffusi. Per installare WordPress su una quota Server, su questa deve essere presente anche PHP, e deve esistere nella versione compatibile con la versione WordPress che si sta andando a installare. Per dare un’idea, negli ultimi 5 anni si sono avvicendate 9 nuove versioni di PHP e 148 diverse versioni di WordPress, comprendendo anche i branch.

Piccolo inciso, i branch sono quelle biforcazioni nel percorso di sviluppo del software per cui una versione precedente del software riceve parallelamente degli aggiornamenti relativi, perlopiù alla sicurezza, al fine di tenere vivo il software in uno stato di compatibilità con altri software la cui interazione è strategica. Un po’ come quando Windows tenne Xp operativo negli aggiornamenti di sicurezza per i bancomat e per i totem.

Questo potrebbe rasserenare il cliente sulla necessità di aggiornare spesso, ma le variabili da tenere in considerazione sono tante, e aumentano per ogni plugin presente in più sul progetto. E abbiamo accennato solo a PHP e WordPress, ma quest’ultimo chiama in sinergia tanti altri linguaggi di programmazione, e anche questi sono soggetti ad aggiornamenti.

Poi certo, su WordPress c’è la possibilità di attivare gli aggiornamenti automatici dei plugin. Ma i plugin non sono sviluppati tutti dalla stessa software house, quindi una prima di un’altra potrebbero decidere di migrare a una nuova versione dello stesso linguaggio di programmazione (teniamo l’esempio di PHP), aggiornando parti del codice (chiamate, funzioni) che risulterebbero in errore mantenendo la versione precedente di PHP. Il plugin funzionerebbe male e di conseguenza il sito stesso. Impostando però il Server sulla nuova versione di PHP smetterebbero però di funzionare altri due plugin, magari, perché ancora strutturati secondo le regole sintattiche della versione precedente del linguaggio. E questo è il primo dei tanti motivi per cui mandare sempre tutto in aggiornamento automatico non è consigliabile, e questa procedura va affidata periodicamente a dei professionisti, come fosse il tagliando della propria automobile.

Come si presenta un sito WordPress dopo qualche settimana che è stato consegnato.. Oggi plugin non aggiornato è una potenziale breccia per la sicurezza

Tutto il discorso fatto per WordPress vale anche per gli altri progetti, quello che cambia è la periodicità con cui avviene, perché a CMS più specializzato equivale community più piccola e quindi aggiornamenti meno frequenti; ma a community più piccola (seguendo il paradigma spiegato qualche paragrafo fa) equivale anche una maggior complessità del linguaggio di programmazione, quindi maggior criticità per tutte le operazioni di manutenzione.

Abbattere la coda di lavoro

Ora c’è da dire che tutti questi interventi potrebbero essere acquistati alla bisogna, al di fuori di un pacchetto di assistenza. Dovete tenere conto che, per via della competitività del settore, ogni web agency è costantemente impegnata su diverse commesse contemporaneamente, con una coda di lavoro organizzata e attentamente distribuita sui clienti in essere. Motivo per cui da un’estemporanea richiesta di assistenza da parte di un vecchio cliente, all’effettiva presa in carico e risoluzione del problema potrebbero passare anche alcuni mesi. Acquistare, insieme al sito, un pacchetto di assistenza in ore annuali, permette al cliente di rimanere tale e di scavalcare la coda di lavoro con dei tempi massimi di intervento garantiti.

Ci abbiamo messo un po’ ma siamo arrivati, senza saltare passaggi, a farvi comprendere l’importanza di un pacchetto d’assistenza. Scriveremo ancora articoli di questo tipo, perché possiate progredire nella vostra idea progettuale senza gli ostacoli dati dalle errate convinzioni e dai falsi miti che circolano a proposito del mondo del web developing. Continuate a seguirci!