Seguici su Telegram, ne vale la pena ❤️ ➡ @trovalost
Vai al contenuto

Come personalizzare il backend di WordPress

Tag:

Le modifica al backend di WordPress (la sua parte amministrativa, ovvero l’editor assegnato alle varie utenze amministratore, editore, ecc.) sono tipiche di buona parte delle personalizzazioni: sono il motivo, in altri termini, per cui i nostri clienti si rivolgono a noi piuttosto che sfruttare soluzioni preimpostate per la realizzazione di siti. Da un punto di vista tecnico, la modifica al backend di WordPress è formalmente molto complessa: se nel caso delle modifiche al theme, infatti, strumenti quali le action, i filtri ed i temi child, nel caso delle modifiche all’editor interno bisogna intervenire sfruttando una combinazione di elementi. Roba che provoca forti mal di testa al webmaster occasionale, ma che lo sviluppatore medio dovrebbe essere in grado di manipolare con un po’ di pratica.

Non esiste infatti un modo per intervenire sul backend che sia semplice & veloce, anche perchà© è stato programmato in modo piuttosto complicato (e criticato da molti, per questo): non è pensato, insomma, per le modifiche, eppure ci proveremo lo stesso.

Come modificare il backend … nel peggiore dei modi

àˆ utile partire da quello che non bisogna fare, per cui capire per esclusione come muoverci: la nostra necessità  di modificare il backend di WordPress è, nella maggioranza dei casi, legata al voler semplificare la vita all’utente finale: obiettivo più che lecito, ovviamente, dato che le numerose opzioni presenti all’interno del men๠originale potrebbero sembrare di troppo alla maggioranza degli utilizzatori del sito. Complicare il codice per un obiettivo del genere è chiaramente un controsenso, senza contare che in alcuni casi vorremmo non dare la possibilità  al cliente di cambiare il theme o modificare i plugin, lasciando pero’ la possibilità  di aggiornarli in modo autonomo. Un complesso gioco di equilibri che deve prevedere, insomma, di evitare che l’utente “faccia danni” irreversibili.

L’approccio tipico, in molti casi pratici di mia conoscenza, parte male, anzi malissimo: il tipico modus operandi prevede, infatti, di intervenire sul codice sorgente di WP, o peggio ancora modificare in modo arbitrario i roles di WordPress, il che sembrerebbe la soluzione drastica & indolore ai nostri problemi. A lungo andare, pero’, questo approccio ci spinge – a parte a scrivere codice in più – ad aggirare i controlli del CMS, finendo per degenerare la nostra personalizzazione in un classico caso di spaghetti code (codice difficile da modificare, mantenere e decifrare).

Come creare, modificare e mantenere un backend WordPress a prova di utonto

In onore al principio KISS (Keep It Simple, Stupid) di semplificazione massima del codice, i possibili approcci ad una modifica safe del codice del backend di WP potrebbero essere i seguenti.

  1. Creare prima di tutto una gerarchia di utenti sensata, cioè non dare a tutti privilegi di amministratore: già  assegnare in modo corretto la tipologia di utenze, infatti, senza bisogno di essere un programmatore provetto (può farlo anche il solo amministratore del sito), permette di fare più cose di quelle che potremmo pensare. Se un utente è amministratore, vede il backend classico nella sua interezza; se è editore, vede un po’ meno e cosଠvia, arrivando ai ruoli base che hanno il backend più essenziale e che, di fatto, in molti casi potrebbero coincidere con il livello di “visibilità ” che vogliamo dare al cliente finale. Perdiamo quindi un po’ di tempo a studiare il ruolo dei ruoli, invece di lanciarci in improbabili modifiche al codice (che, in molti casi, rischiano di andare perdute per sempre al prossimo aggiornamento del core).
  2. Evitare tassativamente di modificare il codice di WP “a crudo”, perchè le modifiche andranno perse al prossimo update del core. Insomma farete un lavoraccio che sarà  invalidato al successivo aggiornamento (in media, WP ne fa uno al mese); qualche “genio”, a riguardo, valuta di disabilitare gli aggiornamenti per poter “lavorare in pace”. L’approccio è completamente sballato, ovviamente, oltre che molto rischioso sul piano della sicurezza.
  3. Evitare tassativamente, per ragioni simili, di editare i plugin, che non sono pensati per modifiche “in corsa”: l’approccio corretto prevede, semmai, di creare da zero dei plugin propri.
  4. Impostare da subito gli aggiornamenti automatici di theme e plugin, ed impedire che si possa mettere mano ad essi; per farlo, bastano delle semplici opzioni all’interno del wp-config.php. Questo permetterà  di mantenere stabile e pulito il vostro nuovo sito: il mio suggerimento è quello di farlo sempre, anche se l’utonto medio non apprezza queste cose (finchè, un giorno, non si ritroverà  col sito compromesso).
  5. Molte feature o caratteristiche parecchio richieste sul backend sono, in effetti, disponibili in plugin già  pronti all’uso: un esempio potrebbe essere Admin Columns, che potete installare per avere la possibilità  di modificare l’ordine ed il tipo delle colonne nell’editor dei post. Già  la versione di base di questo menu editor permette di fare un bel po’ di cose (c’è una versione a pagamento che aggiunge i filtri di ricerca, ad esempio), tra cui: aggiungere colonne, rimuovere colonne di troppo, riordinarne, decidere se nasconderle via CSS o togliere del tutto le funzionalità  extra. Un altro plugin simile è Codepress Admin Columns, che offre addirittura qualcosa in più, oppure – ancora – Backend Localization che permette di cambiare la lingua solo del backend; esistono altri plugin come Back End Instructions che pero’, al momento in cui scrivo, non sono aggiornati da molto. Potete provarli a vostro rischio e pericolo, o sfruttarli come base per ideae un plugin vostro, a patto che sappiate programmare un po’ meglio – per usare un eufemismo – della media degli sviluppatori WP. In ogni caso, sebbene i plugin lato backend non siano troppo diffusi, sappiate che esistono, che possono aiutarvi a semplificare alcune cose, e che nel 99% dei casi, da soli, non vi permetteranno di soddisfare la vostra lista di requisiti. Non ve la caverete solo installando plugin, insomma, ma di sicuro è bene sapere che certe cose esistono.
  6. Sfruttare le action ed i filtri appositi, quelli che permettono (nel caso più semplice) di aggiungere delle alert o degli avvisi nel backend, passando per i tipici controlli del codex che aggiungono comportamenti in base alla natura dell’utente corrente. Queste funzioni sono spesso poche righe di codice che permettono interventi “puntuali” molto specifici, e che si rivelano molto utili in fase di test, soprattutto; col tempo capirete bene come sfruttarle e ad apprezzarne la potenza. Questa fase è forse la più difficile ma è anche l’unica davvero valida: difficile da scrivere, difficile da testare ma i risultati saranno quantomeno stabili e sicuri. Action tipiche di base utili per approcciare nel modo giusto sono, ad esempio: admin_init, wp_dashboard_setup, admin_head, admin_footer e admin_enqueue_scripts.
  7. Sfruttare di più i framework, cosa di cui ho parlato più volte su questo sito (e che stranamente viene ancora ignorata dallo sviluppatore medio): ad esempio basta installare OFT nella directory del vostro theme child per disporre di una nuova pagina di opzioni pronta ad essere personalizzata. Il caso tipico di applicazione di questo framework è quello in cui dobbiamo offrire al cliente finale delle etichette modificabili, dei campi testo editabili ed altre opzioni radio e/o on/off. In casi più complessi, potete trovare ambiente del genere ancora più elaborati: tutto dipende da quello che dovete fare e dal vostro budget, visto che alcuni di essi sono a pagamento.
  8. Se possibile, infine, evitare di manipolare i roles, anche se esistono molti plugin che permettono di farlo; dal mio punto di vista, anche se statisticamente il sito continuerà  a funzionare lo stesso, potrebbero generarsi errori imprevisti quando meno ce lo aspettiamo, complicando notevolmente – ed in modo inutile – la gestione del codice.

Le modifiche al backend di WordPress sono un’arma infida, quindi: WP non è pensato per modifiche del genere, e molti potrebbero pensare ad un’alternativa come Drupal che, ad esempio, offre funzionalità  simili (sia da blog che da CMS) anche decisamente più potenti. Il problema è che si basa su un mix – per molti troppo difficile anche solo da concepire – tra la classica programmazione ad oggetti (OOP) che la sua evoluzione AAP: abbastanza perchè la maggioranza degli sviluppatori cerchi di starne alla larga.

Eppure le richieste di modifiche del genere sono sempre vive, per cui a questo punto c’è da augurarsi che le cose possano semplificarsi anche per WordPress, in un prossimo futuro.

Photo by Mike Licht, NotionsCapital.com, tratta da “Il prestigiatore” di Hieronymus Bosch

👇 Da non perdere 👇

Questo sito web esiste da 4462 giorni (12 anni), e contiene ad oggi 6699 articoli (circa 5.359.200 parole in tutto) e 13 servizi online gratuiti. – Leggi un altro articolo a caso
Non ha ancora votato nessuno.

Ti sembra utile o interessante? Vota e fammelo sapere.

Leggi anche:
Questo sito contribuisce alla audience di sè stesso.
Il nostro network informativo: Lipercubo.it - Pagare.online - Trovalost.it.