WordPress Admin Decluttering: la Legge della Sottrazione e Access Control via MU-Plugin

Una bacheca di WordPress sovraccarica di moduli inutilizzati, strumenti orfani e relitti legacy genera rumore cognitivo, aumenta il rischio di errori umani da parte del team editoriale e degrada l’esperienza d’uso complessiva.

La soluzione comune sul mercato consiste nell’installare plugin di «White Label» o «Admin Customizer». Questo approccio viola i principi di un’architettura enterprise: introduce decine di kilobyte di script non necessari nel backend, appesantisce la tabella wp_options con query lente e allarga la superficie d’attacco con codice di terze parti non controllato.

1. Debito tecnico dell’interfaccia: rumore cognitivo e voci orfane

Quando un’infrastruttura WordPress viene opportunamente blindata e ottimizzata, molte delle funzionalità standard del core perdono la loro ragion d’essere:

• Menu «Discussione» orfano: Se i commenti sono disattivati nativamente su post, pagine, REST API e feed XML, mantenere visibile il sotto-menu Impostazioni → Discussione espone solo decine di checkbox inattive che confondono chi gestisce il sito.
• Importatori legacy e conflitti di tassonomia: Nella sezione Strumenti → Importa risiedono script per piattaforme ormai dismesse (Blogger, LiveJournal, Movable Type) e il «Convertitore di categorie e tag». Se la tassonomia dei tag è stata rimossa per azzerare la duplicazione di contenuti, quello strumento rappresenta un controsenso architetturale.
• Strumenti GDPR per siti cookieless: Le schermate Esporta dati personali ed Elimina dati personali sono concepite per gestire richieste di commentatori e utenti registrati. Su portali B2B, siti vetrina ed editoriali privi di autenticazione pubblica e con tracciamento cookieless, questi form restano gusci vuoti.

2. Livello 1 (UI Masking): Pulizia visiva con remove_submenu_page

La pulizia dell’interfaccia si implementa con il costrutto nativo remove_submenu_page(), agganciato all’action admin_menu con priorità tardiva (99). Questa configurazione assicura che il nostro codice intervenga dopo che WordPress e qualsiasi estensione abbiano registrato i rispettivi menu:

<?php
/**
 * Rimozione menu e sotto-menu orfani (Legge della Sottrazione).
 */
add_action( 'admin_menu', function() {
    // Rimuove 'Discussione' da Impostazioni (commenti disattivati a monte)
    remove_submenu_page( 'options-general.php', 'options-discussion.php' );

    // Rimuove 'Importa' da Strumenti (previene uso importatori obsoleti)
    remove_submenu_page( 'tools.php', 'import.php' );

    // Rimuove utility personali GDPR (architettura priva di utenti/commenti)
    remove_submenu_page( 'tools.php', 'export-personal-data.php' );
    remove_submenu_page( 'tools.php', 'erase-personal-data.php' );
}, 99 );

Questo blocco opera direttamente in RAM modificando l’albero di navigazione prima che venga inviato al browser, senza scrivere nulla a database e senza caricare file CSS o JS aggiuntivi.

3. Livello 2 (Access Control Enforcement): Oltre la «Security through Obscurity»

Nascondere un link da un menu (UI Masking) non significa impedire l’accesso alla risorsa. Se un utente autenticato digita direttamente l’URL nella barra del browser (ad esempio /wp-admin/import.php), WordPress caricherà la pagina senza ostacoli.

Per completare la blindatura è necessario un controllo di accesso (Access Control Enforcement) sull’hook admin_init. Intercettando la variabile globale $pagenow, verifichiamo la rotta richiesta ed espelliamo l’utente prima ancora che la pagina venga elaborata:

/**
 * Access Control Enforcement: Reindirizza chi tenta l'accesso diretto via URL.
 */
add_action( 'admin_init', function() {
    global $pagenow;

    $disallowed_pages = array(
        'options-discussion.php',
        'import.php',
        'export-personal-data.php',
        'erase-personal-data.php',
    );

    if ( in_array( $pagenow, $disallowed_pages, true ) ) {
        wp_safe_redirect( admin_url() );
        exit;
    }
} );

Chiunque tenti di richiamare le rotte dismesse – per distrazione, segnalibri memorizzati o tentativi di probe – viene reindirizzato in pochi millisecondi alla dashboard principale (302 Redirect), preservando la coerenza dell’applicazione.

4. Perché usare i Must-Use Plugins (mu-plugins) e non il tema

Inserire logiche di questo tipo nel file functions.php del tema attivo è una pratica sconsigliata. I Must-Use Plugins (collocati nella directory wp-content/mu-plugins/) garantiscono tre vantaggi tecnici insostituibili:

• Esecuzione prioritaria: Vengono caricati dall’interprete PHP prima di qualsiasi plugin standard e prima del tema, garantendo un controllo tempestivo sulle pipeline di richiesta.
• Persistenza totale: Gli aggiornamenti del core di WordPress non toccano mai il contenuto di wp-content/. Le regole definite restano operative e immutabili nel tempo.
• Disaccoppiamento dal design: Se il tema grafico o i template Full Site Editing vengono aggiornati, rifiniti o sostituiti, l’architettura di hardening e decluttering della bacheca rimane intatta.