Dove mettere il mio codice: plugin o functions.php?

Question

Dove mettere il mio codice: plugin o functions.php?

18 nov 2012, 12:51:04

Visualizzazioni: 18.2K

Voti: 100

Esiste uno schema facile da comprendere per decidere quale tipo di codice appartiene a un plugin o al file functions.php del tema?

Ci sono molti casi e numerosi dibattiti su questo argomento, principalmente perché esistono alcuni malintesi sul funzionamento interno di WordPress. Sto cercando una risposta basata sui fatti, non sulle opinioni.

Dovrebbe spiegare come gestire questi punti (e probabilmente altri):

tipi di post personalizzati e tassonomie
moduli di contatto
shortcode
widget personalizzati
add_theme_support( 'automatic-feed-links' );
funzioni SEO come elementi meta personalizzati
cambio tema

Spesso ci sono pro e contro per entrambe le soluzioni. La nostra domanda più popolare Migliore Raccolta di Codice per il tuo file functions.php ha ricevuto molti snippet di codice come risposte che sono quanto meno discutibili.
Abbiamo bisogno di criteri che un principiante possa capire, magari una checklist - con motivazioni.

Vedi anche la domanda correlata di Chip Bennett sul nostro sito meta: Domande che chiedono specificamente una soluzione "senza plugin"

Correlato: Dove metto gli snippet di codice che ho trovato qui o da qualche altra parte sul web?

fuxia

107K

tipi di post personalizzati sviluppo plugin sviluppo temi widget shortcode

Commenti

Mi chiedo cosa costituirebbe un fatto a questo proposito. La persona A dice che i CPT vanno nel plugin, la persona B dice che i CPT vanno nel tema. Come possiamo procurarci un fatto per validare una delle due opinioni? Questo potrebbe avvicinarsi pericolosamente al "non costruttivo".

Rarst

18 nov 2012 20:24:01

Tutte le risposte alla domanda

Commenti

add_theme_support( 'automatic-feed-links' ); non è presentazionale. Ma è richiesto dalle linee guida del tema. Perché è un rischio necessario perdere questa funzionalità dopo un cambio di tema?

fuxia

20 nov 2012 00:01:54

Tutto ciò che viene implementato tramite add_theme_support() può essere implementato solo tramite il Tema. Usare add_theme_support( 'automatic-feed-links' ) all'interno del Tema in realtà garantisce un'esperienza coerente da un Tema all'altro, poiché i link dei feed generati saranno gli stessi.

Chip Bennett

20 nov 2012 00:48:19

Penso che sia chiamato male: i link dei feed non sono presentazionali. Se il prossimo tema non chiama quella funzione l'utente perderà i link dei feed. E puoi aggiungerlo tramite plugin senza alcun problema. Ecco perché sono confuso al riguardo. :)

fuxia

20 nov 2012 00:55:41

Sai una cosa: hai ragione. :)

Chip Bennett

20 nov 2012 01:49:30

Un semplice test per capire dove posizionare al meglio il codice:

scrivi il codice nel file functions.php
cambia tema
manca la funzionalità, il blog non funziona correttamente o rimangono frammenti del vecchio tema (es. shortcode)?
- sì: inseriscilo in un plugin
- no: lascialo nel functions.php

Esempi: Scrivi uno shortcode. Dopo aver cambiato tema, gli shortcode rimangono visibili nei tuoi articoli. In questo caso è meglio inserirlo in un plugin.

Scrivi una funzione per elencare gli ultimi commenti. Dopo aver cambiato tema, tutto funziona perché magari l'altro tema ha una funzione equivalente.

Dipende molto dal codice e da cosa fa. Alcuni codici influenzano solo lo stile o il contenuto del tema, altri modificano gli articoli del blog.

Ralf912

5.31K

18 nov 2012 14:26:06

Commenti

+1 Se il codice è specifico per il tema, inseriscilo in functions.php. Se deve essere applicato a più temi, inseriscilo in un plugin.

s_ha_dum

18 nov 2012 17:15:51

Non credo ci sia una risposta semplice a questa domanda, ma scommetto che potremmo creare un diagramma di flusso per aiutare nella decisione. Ecco una bozza approssimativa di tale diagramma, che può e dovrebbe essere ampliata. Commentate con i vostri suggerimenti!

Questo codice deve essere ospitato su un'installazione WordPress single-site?
- Sì - Il tema del sito cambia solo con ridisegni importanti e cambiamenti di funzionalità?
  - Sì - Il codice in questione è specifico per questo design attuale?
    - Sì: functions.php
    - No: Plugin
  - No (cambia spesso o a piacimento) - Plugin
- No (Multisite) - Stai ospitando l'installazione multisite OPPURE è una soluzione multisite ospitata che permette plugin?
  - Sì: La funzionalità in questione è specifica per questo sito, o può/dovrebbe essere usata da altri siti nella rete?
    - Specifica per questo sito: functions.php
    - Condivisa tra più siti - Vuoi imporla su ogni sito?
      - Sì: Plugin, salvato nella directory mu-plugins o attivato a livello di rete
      - No: Questa è una rete di siti non correlati? (es. clienti diversi)
        
        Sì: Sarebbe negativo o poco professionale se il cliente A vedesse o attivasse il plugin scritto per i clienti B, C e D? (es. potrebbe rompere il sito o causare funzionalità indesiderate)
        
        Sì: functions.php
        
        No: Plugin
        
        No: Probabilmente plugin
  - No (ospitato da un servizio come VIP che non permette plugin): usa functions.php

Alcune altre considerazioni che non sapevo come inserire qui:

Temi genitore -- a volte con funzionalità condivise sarebbe meglio creare un tema genitore e mettere la funzionalità nel file functions.php del tema genitore.
Le directory dei plugin di grandi installazioni multisite possono rapidamente diventare ingestibili, quindi a volte funzionalità condivise usate da una bassa percentuale di siti (es. < 1%) sarebbe meglio duplicarle nei file functions.php.

Matthew Boynes

7.12K

8 dic 2012 19:23:54

Da qui Temi VS Plugin

Aggiungi codice personalizzato a un tema child in modo che quando aggiorni il tema genitore, il tuo codice personalizzato non vada perso.

Puoi anche creare un plugin specifico per il sito che contenga tutto il tuo codice personalizzato.

Per quanto riguarda la scrittura di codice rispetto ai plugin, puoi utilizzare i plugin e le funzioni, tuttavia per la maggior parte delle tue esigenze, scrivere codice manualmente è la soluzione migliore poiché è più facile da modificare, tranne in alcuni casi come i meta box dove potresti considerare l'uso di un plugin a meno che tu non sia uno sviluppatore di temi.

 function modify_contact_methods($profile_fields) {

// Aggiungi nuovi campi
$profile_fields['twitter'] = 'Nome utente Twitter';
$profile_fields['facebook'] = 'URL Facebook';
$profile_fields['gplus'] = 'URL Google+';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

Aggiungi un nuovo custom post type - Codice
Aggiungi nuovi campi agli Utenti - Codice Sopra
Aggiungi nuovi widget - Codice
Aggiungi permalink personalizzati - Impostazioni Permalink di WordPress

Brad Dalton

6.97K

4 feb 2014 23:00:39

So che questo è un argomento già ampiamente discusso e che Chip l'ha già coperto in modo esaustivo, ma volevo aggiungere qualche pensiero.

Se programmare è il tuo lavoro e ti ritrovi a lavorare su siti WordPress con scadenze strette, scoprirai che tutto si riduce al fattore tempo.

Molto spesso, specialmente per chi è agli inizi, è molto più veloce e semplice aggiungere ciò che ti serve direttamente nel tema e dare il lavoro per concluso.

Detto questo, se lavori con WordPress con una certa regolarità, dovresti seriamente considerare di fare quanto segue:

Crea uno scheletro di plugin

Dovrebbe gestire tutto ciò che comunemente ti serve fare con un plugin, inclusi attivazione, disattivazione, aggiornamento della versione, creazione di pannelli di amministrazione e disinstallazione.

Se trovi il tempo per farlo, scoprirai che:

Non ci vuole molto tempo extra per aggiungere funzionalità tramite plugin
Puoi iniziare a costruire una solida lista di plugin da riutilizzare in altri progetti quando necessario, risparmiando molto tempo nel lungo periodo.
Puoi renderli pubblicamente disponibili se desideri maggiore visibilità

Ora puoi costruire le cose nel modo corretto e completare i progetti futuri più velocemente.

Crea uno scheletro di tema

Dovrebbe gestire tutto ciò che è comunemente necessario in un tema:

Un foglio di stile principale contenente gli stili che usi più frequentemente (resets, ecc.)
Un file index.php corretto, che gestisca tutto ciò che ti serve per qualsiasi template
Un file functions.php - non lo userai così spesso, ma tornerà comunque utile.

Una volta fatto ciò, crea uno scheletro di child theme che utilizzi il tuo tema principale.

Aggiungi il foglio di stile, referenziando il tuo tema genitore.
Aggiungi il file functions.php

Una volta completati questi due passaggi, creare nuovi siti per i clienti diventerà molto più veloce.

Se fai quanto sopra, potrai poi concentrarti su:

Usare il tempo libero guadagnato per approfondire la conoscenza di PHP, WordPress, JavaScript, CSS e/o mySQL... più impari di queste tecnologie, più velocemente completerai il lavoro.
Aggiornare gli scheletri di plugin, tema e child theme man mano che trovi aspetti da migliorare. Non importa quanto tu sia bravo, se continui a imparare troverai sempre margini di miglioramento.

E, se fai tutto quanto sopra, scoprirai che la risposta di Chip non solo sarà ideale, ma diventerà ottimale.

Privateer

1.91K

28 gen 2015 03:17:24

La risposta semplice è questa..

Il codice dipende da una qualsiasi delle funzionalità integrate in un tema specifico? Se sì, allora inseriscilo nel tema.

Vuoi che questo codice sia trasferibile tra siti e tra temi? Se sì, allora inseriscilo in un plugin.

Se la risposta è no a entrambe le domande precedenti, allora immagina il sito tra 5 anni, quando sarà il momento di un restyling. La funzione del codice che stai scrivendo è qualcosa che sopravviverà al prossimo aggiornamento del design? Se sì, inseriscilo in un plugin.

Inoltre, se non stai utilizzando temi child e prevedi di aggiornare il tema, ti suggerirei anche di usare un plugin.

CO4 Computing

41

26 ott 2015 07:28:49

Per rispondere all'OP:

Tipi di post personalizzati e tassonomie

Dovrebbero andare in un plugin poiché definiscono elementi a livello strutturale/conettuale, non a livello di presentazione

Moduli di contatto

Sono elementi di presentazione e dovrebbero essere nelle funzioni del tema

Shortcode

Nel plugin in quanto strutturali

Widget personalizzati

Sono principalmente elementi di presentazione e dovrebbero stare nelle funzioni del tema

add_theme_support( 'automatic-feed-links' );

Il supporto del tema va nelle funzioni del tema

Funzioni SEO come meta elementi personalizzati

Presentazione, quindi nelle funzioni

th00ht

174

18 set 2022 20:27:38

Chip Bennett 55.1K · Accepted Answer · 2012-11-19T14:53:58Z

Vorrei iniziare con questa domanda: La funzionalità è legata alla presentazione dei contenuti, o alla generazione/gestione dei contenuti, del sito o dell'identità utente?

Se la funzionalità non è legata specificamente alla presentazione dei contenuti, allora rientra chiaramente nel territorio dei Plugin. La lista è lunga:

Modificare i filtri core di WP (contenuti di wp_head, come link canonical, meta HTML del generatore, ecc.)
Favicon del sito
Shortcode nei contenuti dei post
Link di condivisione dei post
Script di Google Analytics (e simili) nel footer
Strumenti/controlli SEO
ecc.

Se la funzionalità è legata alla presentazione dei contenuti, allora è un candidato per essere inclusa nel Tema. A questo punto, tornerei al criterio del cambio Tema di @Raf912: ti mancherebbe questa funzionalità se cambiassi Tema? Se la risposta a questa domanda è no, allora la funzionalità appartiene al Tema. Alcuni esempi:

Rimuovere/sostituire il CSS core della Galleria di WP
Filtrare la lunghezza degli excerpt, il testo "leggi tutto", ecc.
Qualsiasi cosa implementata tramite add_theme_support() (suppongo che questo sia ovvio)
CSS personalizzato

Normalmente, queste due domande forniranno una linea di demarcazione abbastanza chiara; tuttavia, ci sono eccezioni.

Custom Post Types

I Custom Post Types, ad esempio, sono un ibrido unico tra generazione e presentazione di contenuti, dato il modo in cui funziona la Template Hierarchy per le pagine di archivio e le pagine singole dei post type. L'aspetto di generazione dei contenuti dei CPT li collocherebbe normalmente nel territorio dei Plugin; tuttavia, i Plugin non possono definire pagine template che si integrino perfettamente con il design/layout/stile di un qualsiasi Tema (specialmente se il CPT mostra elementi diversi dai soliti Titolo/Contenuto/Meta, o ha taxonomie personalizzate associate).

A lungo termine, la soluzione a questa disparità, secondo me, è avere una convenzione/consenso standard per la definizione dei CPT per determinati tipi di contenuti (annunci immobiliari, eventi di calendario, prodotti e-commerce, voci di libreria di libri/media, ecc.). In questo modo, i contenuti generati dagli utenti rimarrebbero portabili tra Temi che implementano la definizione standard/convenzionale di un dato CPT, mentre gli sviluppatori di Temi mantengono la flessibilità di definire il design/layout/stile di quel CPT nei file template del Tema.

Link ai Social Media

Allo stesso modo, normalmente direi che i link ai profili social, diventati ormai onnipresenti nei Temi attuali, sono territorio dei Plugin, perché non hanno nulla a che fare con la presentazione dei contenuti. La soluzione migliore sarebbe che questi profili fossero definiti da qualche parte nel core; tuttavia, al momento non esiste un modo standard/condiviso per definire questi link. È meglio definirli a livello di impostazioni del sito, o per ogni utente? Se per utente, quali meta dell'utente vengono esposte nel template? ecc.

Quindi, ancora una volta, a lungo termine la soluzione a questa disparità è che il core definisca dove questi link vengono definiti, o che la community degli sviluppatori di Temi sviluppi un proprio consenso. Nel frattempo, non c'è davvero altra soluzione se non mantenerli definiti all'interno di ogni Tema.