Categoria: Web Design

  • Hai mai pensato di creare un tuo plugin per WordPress? Può sembrare complicato, ma con gli strumenti giusti e un approccio passo-passo, è più accessibile di quanto pensi. In questo post, vedremo come creare un plugin semplice ma utile: una modalità di manutenzione personalizzabile per il tuo sito. Seguiremo insieme l’intero processo, dalla scrittura del codice alla preparazione per la distribuzione, inclusa la traduzione multilingua e il controllo di conformità. Per esemplificare il processo utilizzeremo un caso reale: la creazione di un plugin di manutenzione per i miei clienti del mio brand OperWEB.

    Cosa creeremo: Un plugin “OperWEB Maintenance Mode” (ma voi chiamatelo come volete) che:

    • Mostra una pagina di manutenzione personalizzata ai visitatori.
    • Permette agli amministratori di vedere il sito normalmente.
    • Ha una pagina di impostazioni per attivare/disattivare, caricare un logo, inserire testo e scegliere colori.
    • È traducibile in diverse lingue (Italiano e Inglese inclusi).
    • È conforme agli standard di WordPress.org.

    Strumenti che useremo:

    • Un editor di codice (es. VS Code, Sublime Text, ecc.)
    • Una installazione locale o di test di WordPress
    • Il plugin Loco Translate (gratuito)
    • Il plugin Plugin Check (gratuito, da WordPress.org)

    1. La Struttura Base del Plugin

    Ogni plugin inizia con una cartella e un file PHP principale.

    1. Crea la Cartella: Dentro la tua cartella wp-content/plugins/, crea una nuova cartella. Chiamiamola operweb-maintenance-mode.
    2. Crea il File Principale: Dentro questa cartella, crea un file chiamato operweb-maintenance-mode.php.
    3. L’Intestazione (Header): Apri il file e inserisci l’intestazione PHP. Questa dice a WordPress tutto sul tuo plugin:
    <?php
    /**
     * Plugin Name:       OperWEB Maintenance Mode
     * Description:       Attiva una pagina di manutenzione personalizzata con opzioni.
     * Version:           2.3.3
     * Author:            Fabrizio Ortis | OperWEB
     * Author URI:        https://www.operweb.com
     * License:           GPL v2 or later
     * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
     * Text Domain:       operweb-maintenance-mode
     * Domain Path:       /languages
     */
    
    // Impedisci l'accesso diretto
    if ( ! defined( 'ABSPATH' ) ) {
        exit;
    }
    
    // ... il resto del codice del plugin andrà qui ...

    Plugin Name, Description, Author, etc.: Informazioni mostrate nella bacheca.

    License: Fondamentale per la distribuzione (GPLv2 or later è lo standard).

    Text Domain & Domain Path: Cruciali per le traduzioni (ne parleremo dopo).

    2. La Logica Principale: Mostrare la Pagina

    Vogliamo che il nostro plugin controlli ogni caricamento di pagina sul frontend e, se necessario, mostri la pagina di manutenzione. Usiamo l’hook template_redirect.

    function owm_maintenance_mode_check() {
        $options = get_option( 'owm_options' ); // Legge le impostazioni (che creeremo dopo)
    
        // 1. Manutenzione attiva dalle impostazioni?
        if ( empty( $options['enable'] ) || $options['enable'] != 1 ) {
            return; // No, non fare nulla.
        }
    
        // 2. L'utente è un admin?
        if ( current_user_can( 'manage_options' ) ) {
            return; // Sì, mostra il sito normale.
        }
    
        // 3. Per tutti gli altri: mostra la pagina di manutenzione
        $maintenance_file = plugin_dir_path( __FILE__ ) . 'maintenance.php'; // Il nostro file template
        if ( file_exists( $maintenance_file ) ) {
            // Invia header HTTP 503 (importante per SEO)
            if ( ! headers_sent() ) {
                header( 'HTTP/1.1 503 Service Unavailable', true, 503 );
                header( 'Content-Type: text/html; charset=utf-8' );
                header( 'Retry-After: 3600' ); // Riprova tra 1 ora
            }
            // Carica il template e ferma WordPress
            include( $maintenance_file );
            die();
        }
    }
    add_action( 'template_redirect', 'owm_maintenance_mode_check' );

    Avremo bisogno anche di un file maintenance.php nella stessa cartella, che conterrà l’HTML e il CSS della nostra pagina (lo vedremo dopo).

    3. Creare una Pagina di Impostazioni (Settings API)

    Per permettere all’utente di configurare il plugin, usiamo la Settings API di WordPress. È un po’ “verbosa” ma potente.

    1. Aggiungere la Pagina: Usiamo add_options_page() per aggiungere una voce sotto “Impostazioni” nel menu admin.
    2. Registrare le Impostazioni: Con register_setting(), diciamo a WordPress quale opzione salvare nel database (es. owm_options) e quale funzione usare per “pulire” i dati (owm_sanitize_options).
    3. Definire Sezioni e Campi: Usiamo add_settings_section() e add_settings_field() per definire la struttura della pagina e i singoli campi (checkbox, uploader logo, editor testo, color picker).
    4. Funzioni Callback: Ogni campo ha bisogno di una funzione PHP che stampa il suo HTML (es. owm_field_enable_cb() per la checkbox).
    5. Render Pagina: Una funzione (owm_options_page_html()) stampa l’HTML base della pagina, il tag <form> e usa settings_fields() e do_settings_sections() per far apparire tutto.

    (Nota: Il codice completo per la Settings API è abbastanza lungo, lo trovi nel file finale del plugin che trovi in fondo al post e potrai modificare liberamente. Qui ci concentriamo sui concetti).

    Per campi avanzati come l’uploader media e il color picker, dobbiamo anche “accodare” gli script e gli stili necessari usando wp_enqueue_media(), wp_enqueue_style('wp-color-picker') e wp_enqueue_script().

    4. Internazionalizzazione (i18n): Preparare per la Traduzione

    Per rendere il plugin multilingua:

    1. Text Domain & Domain Path: Assicurati che siano definiti nell’header del plugin. Text Domain è un identificatore unico (es. operweb-maintenance-mode), Domain Path dice a WordPress dove trovare i file di lingua (es. /languages).
    2. Marcare le Stringhe: Ogni stringa di testo visibile all’utente (nel backend o nel frontend) deve essere “avvolta” in una funzione di traduzione:
      • __( 'Stringa da tradurre', 'operweb-maintenance-mode' ): Restituisce la stringa tradotta (per usarla in variabili o funzioni).
      • _e( 'Stringa da tradurre', 'operweb-maintenance-mode' ): Stampa direttamente la stringa tradotta (echo).
      • esc_html__(...), esc_attr__(...), esc_html_e(...), esc_attr_e(...): Come sopra, ma fanno anche l’escape per sicurezza prima di restituire/stampare.
      • printf() / sprintf(): Se hai variabili dentro una stringa, usa queste funzioni con commenti /* translators: ... */ per spiegare i segnaposto.
      Esempio:
    // Prima:
    echo '<h1>Sito in Manutenzione</h1>';
    // Dopo:
    echo '<h1>' . esc_html__( 'Sito in Manutenzione', 'operweb-maintenance-mode' ) . '</h1>';

    5. Tradurre con Loco Translate

    Ora che il codice è pronto, usiamo Loco Translate per creare i file di lingua:

    1. Installa e Attiva: Aggiungi il plugin Loco Translate al tuo sito di test.
    2. Vai su Loco Translate > Plugins: Trova “OperWEB Maintenance Mode” e cliccaci.
    3. Crea Modello (.pot): Clicca “Crea modello”. Conferma per salvarlo in languages/operweb-maintenance-mode.pot. Questo file contiene l’elenco di tutte le stringhe originali.
    4. Crea Traduzione Italiana (it_IT):
      • Clicca “Nuova lingua”.
      • Scegli “Italiano (Italia)”.
      • Importante: Scegli la posizione “File dell’autore” (salverà in wp-content/plugins/operweb-maintenance-mode/languages/).
      • Clicca “Inizia a tradurre”.
      • Copia ogni stringa sorgente nella casella di traduzione.
      • Clicca “Salva”. Verranno creati it_IT.po (modificabile) e it_IT.mo (compilato).
    5. Crea Traduzione Inglese (en_US):
      • Clicca di nuovo “Nuova lingua”.
      • Scegli “Inglese (Stati Uniti)”.
      • Scegli la posizione “File dell’autore”.
      • Clicca “Inizia a tradurre”.
      • Traduci ogni stringa italiana in inglese.
      • Clicca “Salva”. Verranno creati en_US.po e en_US.mo.

    6. Recuperare i File di Traduzione

    I file .pot, .po e .mo sono stati creati da Loco Translate direttamente sul tuo server, nella cartella /wp-content/plugins/operweb-maintenance-mode/languages/.

    Se non hai lavorato su un server locale devi scaricare questi file (usando FTP, SFTP o il File Manager del tuo hosting) e includerli nella cartella /languages del tuo plugin quando lo distribuisci (es. nello ZIP che caricherai su WordPress.org).

    (Dopo aver recuperato i file, puoi anche disattivare Loco Translate dal tuo sito di test).

    7. Controllo di Conformità con “Plugin Check”

    Prima di pensare alla pubblicazione su WordPress.org, è fondamentale controllare che il tuo plugin rispetti gli standard.

    1. Installa e Attiva: Aggiungi il plugin Plugin Check al tuo sito di test.
    2. Vai su Strumenti > Plugin Check.
    3. Seleziona il tuo plugin (“OperWEB Maintenance Mode”) dal menu a tendina.
    4. Clicca “Check it!”.
    5. Il plugin analizzerà il codice e riporterà eventuali Errori (Errors) e Avvisi (Warnings).
      • Errori: Vanno corretti obbligatoriamente (es. problemi di sicurezza, funzioni deprecate, output non “escapato”).
      • Avvisi: È fortemente consigliato correggerli (es. standard di codice, commenti mancanti per i traduttori).

    Abbiamo visto durante lo sviluppo che questo strumento è molto pignolo. Correggi tutto ciò che riporta, seguendo i link “Approfondisci” che fornisce per capire il problema. Riesegui il check finché non ci sono più errori critici.

    Prossimi Passi: Verso la Pubblicazione

    Con un plugin funzionante, traducibile e controllato, sei pronto per gli ultimi passi prima della distribuzione:

    1. Creare un readme.txt: Questo file (in un formato specifico, non Markdown) è la “vetrina” del tuo plugin su WordPress.org. Deve essere in inglese e descrivere il plugin, l’installazione, le FAQ, ecc. Leggi le linee guida qui.
    2. Preparare lo ZIP: Assicurati che la cartella del tuo plugin contenga tutti i file necessari (PHP, JS, CSS, assets, la cartella languages con i file .pot, .po, .mo, e il readme.txt). Crea un file .zip di questa cartella.
    3. Inviare per la Revisione: Carica il tuo .zip tramite la pagina Add Your Plugin su WordPress.org e attendi la revisione manuale.

    Conclusione

    Creare un plugin per WordPress, anche semplice, tocca molti aspetti dello sviluppo: PHP, API di WordPress, sicurezza, internazionalizzazione. Seguendo questi passaggi e usando strumenti come Loco Translate e Plugin Check, puoi trasformare la tua idea in un plugin robusto e pronto per essere condiviso con la community. Buon coding!

  • Parliamo della cosa più importante per ogni professionista in generale e per ogni Web Designer in particolare: i Soldi.

    A meno che non facciate di cognome Elkann o Vacchi, il vostro lavoro deve darvi la possibilità di vivere e magari anche di andare in vacanza di tanto in tanto.

    Vi capiterà anche (più spesso di quello che immaginate) di essere visitati da 3 terribili tipi di “clienti”, di seguito vi consiglio come gestirli con un pizzico di creatività, d’altronde il nostro è un lavoro creativo.

    1. quello che vuole fare un e-commerce insieme a voi senza nemmeno avere un’idea di cosa vendere, “tanto su Internet si vende”, in questo caso fingete un attacco asmatico e ditegli sibilando che dovete scappare a casa poiché avete dimenticato le medicine, ma appena vi rimettete lo chiamerete sicuramente.
    2. quello che vi dice che ha avuto un’idea bellissima (già è qualcosa), voi gli dovete solo fare il sito e poi dividete in due, il tutto ovviamente senza uno straccio di progetto, non provate a chiedere un business plan, tanto secondo lui non serve, “l’idea è chiarissima e si capisce subito che avrà successo”, ditegli che vi sentite onorati di essere stati scelti per cotanto onore ma non siete degni di avere il privilegio di lavorare con lui perché quando eravate bambini siete caduti dal seggiolone ed ogni tanto vi dimenticate di cosa state parlando. Cosa stavi dicendo?
    3. infine c’è il mio preferito, quello che ha un’azienda/organizzazione/associazione talmente bella e importante che dovreste essere fieri di lavorare per lui anche solo per la visibilità che ne ricavereste. Benché tendenzialmente non violento questo è uno dei pochi casi in cui mi riesce difficile scegliere tra una mazza da baseball o una da hockey 😀

    Partiamo da un presupposto: a meno che non facciate beneficenza un sito fatto professionalmente non può, anzi non deve costare 0 euro, ne va della nostra credibilità di Web Designer.

    Allora quanto ci facciamo pagare? Non esiste una risposta definitiva. Quindi userò un calcolo basato sulle ore impegnate per fare un sito molto basic. Tanti Web Designer storceranno il naso, ma questo è solo un elenco del minimo sindacale, ovvio che un’analisi SEO seria richiede molto più tempo, come anche un lavoro personalizzato sul template, senza contare che, se il sito necessita di codice ottimizzato, si lavora a mano e quindi ci vogliono dalla 5 alle 8 ore solo per fare una pagina.

    In ogni caso da qualche parte dobbiamo pur partire, resto aperto ad ogni suggerimento per migliorare l’elenco dei task necessari.

    Calcoliamo, in via esemplificativa, un sito base non transazionale (non un e-commerce per intenderci) con al massimo una decina di pagine, testi e foto forniti dal cliente, template già fatto su CMS WordPress (circa il 50% dei siti è fatto così).

    • Incontri con il cliente: 6 ore.
    • Registrazione dominio, setup hosting ed email, impementazione cms, setup plugin di sicurezza di base: 4 ore.
    • Revisione testi forniti dal cliente: 4 ore.
    • Selezione e ottimizzazione foto fornite dal cliente: 4 ore.
    • Verifica profili social e presenza su Google Business: 2 ore.
    • Lavorazione logo per la favicon e per le esigenze del cliente (pagina facebook, signature, google+): 2 ore.
    • Creazione cover per profili social: 3 ore.
    • Creazione pagine su template con minimi aggiustamenti CSS: 12 ore.
    • Creazione modulo contatti: 1 ora.
    • Implementazione Analytics e invio sitemap a Google: 2 ore.
    • Verifiche SEO di base (title, description, heading, content): 5 ore.
    • Inserimento informazioni legali (privacy, cookie, ecc.), anche sui social e in calce all’email: 3 ore.
    • Pubblicazione online, ottimizzazione minima della velocità: 2 ore.

    TOTALE: 50 ore.

    Bravura e creatività lasciamoli a parte poiché sono difficilmente quantificabili.

    Decidiamo, quindi, quanto vogliamo prenderci ad ora? 10 euro, 20, 40, 80? Credo che il minimo per un informatico qualificato con un portfolio presentabile sia 24€/ora, quindi la base per un sito Web fatto con tutti i crismi non dovrebbe essere inferiore a € 1.200.
    Prezzo base che sale nel caso in cui il sito eroghi dei servizi oppure sia un e-commerce. Al prezzo base deve, poi, sempre aggiungersi un costo annuale per il rinnovo dell’hosting e la manutenzione (problemi con gli aggiornamenti, attacchi hacker, piccole revisioni dei contenuti, ecc.), quantificabili nell’ordine di qualche centinaio di euro all’anno (dipende molto dal livello di autonomia del cliente).

    Eppure ci sono persone che fanno i siti a 500 o addirittura a 300 euro, com’è possibile? Tralasciando chi lavora a nero, a 300 euro si trovano siti fatti in un paio di giorni di lavorazione, più o meno così:

    • Incontri con il cliente: 2 ore per email o dal vivo.
    • Registrazione dominio, setup hosting ed email, impementazione cms, fatti di fretta: 2 ore.
    • Niente revisione testi.
    • Inserimento delle foto e del logo così come sono: 1 ora.
    • Nessuna verifica profili social e presenza su Google Business.
    • Nessuna attenzione per i social del cliente.
    • Creazione pagine su template senza aggiustamenti: 8 ore (anche di meno).
    • Creazione modulo contatti: 1 ora.
    • Nessuna implementazione statistiche.
    • Nessuna verifica SEO.
    • Nessuna attenzione per le informazioni legali.
    • Pubblicazione online, senza ottimizzazione di base della velocità: 1 ora.

    TOTALE: 15 ore.

    Con 15 ore di lavoro un sito può costare molto poco, specialmente se viene prodotto da un principiante.

    Per finire, la risposta che mi piace dare quando mi chiedono “quanto costa un sito?” è “costa come un vestito!“, infatti un vestito può essere fatto più o meno bene, cucito a mano o prodotto in serie, venduto da un marchio noto o da uno sconosciuto, avere tessuti pregiati oppure economici e così via.

    I vestiti fanno parte della nostra cultura, li usiamo da quando nasciamo, li possiamo toccare, pertanto è più facile valutarli, mentre i siti Web sono relativamente nuovi, sono fatti di bit ed è difficile valutarli senza un minimo di conoscenze specifiche.