Bestway per definire il tema e il percorso e l'URL del plug-in

Sono in disordine. So che questa è una domanda sciocca. Vedi che il percorso del tema non è così buono. Quindi c'è un altro modo? Come posso usare get_template_directory()qui?

    // theme folder path
    if ( ! defined( 'TZSC_THEME_DIR' ) ) {
        define( 'TZSC_THEME_DIR', dirname(__FILE__).'/' );
    }

    // theme folder URL
    if ( ! defined( 'TZSC_THEME_URL' ) ) {
        define( 'TZSC_THEME_URL', plugin_dir_url( __FILE__ ) );
    }

theme-development

— ashraf
fonte

Perché hai bisogno di costanti? Creano una dipendenza aggiuntiva dallo stato globale nel tuo codice. Questo è molto brutto.

— fuxia

Quindi mi consigli di non usarli? Grazie. Influisce sul tempo di caricamento della mia pagina?

— ashraf,

Da PHP 5.4 in poi, le costanti vengono inserite alla fine dello stack, quindi verranno lette più velocemente. Ma il vero problema qui è la qualità del codice: ogni volta che una funzione o una classe usa quella costante, stanno “conoscendo troppo”, fanno un'ipotesi sullo stato al di fuori del proprio codice. Questo non va bene. Rompe l'incapsulamento e rende il codice difficile da leggere. La dipendenza di WordPress dallo stato globale è abbastanza grave. Non peggiorare le cose nel tuo codice.

— fuxia

Non usare costanti per questo. Non usare affatto costanti globali.

Esistono due tipi di costanti: costanti di classe / interfaccia e costanti globali.

Le costanti nelle classi o nelle interfacce vanno bene e talvolta sono utili. Un esempio eccessivamente semplicistico:

interface Requirements
{
    const MIN_PHP_VERSION = 5.4;

    public function php_is_good();
}

class Theme_Requirements implements Requirements
{
    public function php_is_good()
    {
        return version_compare( PHP_VERSION, self::MIN_PHP_VERSION, '>=' );
    }
}

Ma tieni presente che queste costanti sono sempre pubbliche. Se li modifichi in seguito, potresti rompere il codice che dipende da loro.

Questo è peggio con le costanti globali. Immagina quanto segue:

define( 'THEME_URI', get_template_directory_uri() );

E quindi una funzione per un'immagine di intestazione predefinita:

function get_default_header_image()
{
    return THEME_URI . '/img/default-header.jpg';
}

Questa funzione fa un'ipotesi su qualcosa che è fuori dal suo controllo, ne sa troppo. Come testate quella funzione con valori diversi per la costante? Non puoi.

Supponiamo che tu voglia testare cosa succede quando la costante è impostata su una directory inesistente o su un altro server più lento. Ma una volta definita la costante, non è possibile modificarne il valore. Non è possibile eseguire tutti i test in una corsa, questo rende i test più difficili del necessario.

E in un tema figlio che tenta di utilizzare la propria immagine predefinita: come si implementa? La costante è impostata dal tema principale. È possibile aggiungere un controllo condefined() , ma ciò rende più difficile vedere dove è stato effettivamente scritto il suo valore.

Sarebbe molto meglio riscrivere la funzione per:

function get_default_header_image( $base )
{
    return esc_url( $base ) '/img/default-header.jpg';
}

Ho detto prima, le costanti sono un'API. Le API dovrebbero essere facili da modificare, ma è davvero difficile deprecare una costante, perché PHP non registra l'accesso. Quindi il tuo messaggio di deprecazione non raggiungerà mai altri sviluppatori, tranne quando leggeranno il tuo codice sorgente o i tuoi documenti con molta attenzione. Fidati di me, loro no.

Utilizzare get_stylesheet_directory_uri()nei temi figlio e get_template_directory_uri()nei temi padre. Entrambi possono essere filtrati in fase di esecuzione, quindi è possibile eseguire tutti i test contemporaneamente.

— fuxia
fonte