Una delle cose su cui ho fatto uno sforzo molto pi\u00f9 concertato, probabilmente pi\u00f9 di quanto abbia mai fatto prima, \u00e8 la gestione della separazione delle preoccupazioni tra le classi responsabili dell’interfacciamento con WordPress e quelle responsabili del lavoro con il dominio problematico.<\/p>\n
Ad esempio, supponiamo che stai lavorando su un plug-in e comunicher\u00e0 con un’API di terze parti. Inoltre, questo plugin offrir\u00e0 anche menu, tipi di post, tassonomie e cos\u00ec via nell’area di amministrazione di WordPress.<\/p>\n
Ci sono due aree di responsabilit\u00e0 qui:<\/p>\n
Puoi sostenere che \u00e8 importante unit\u00e0 di test delle aree che comunicano con WordPress, ma so anche che queste sono API collaudate e vere che hanno il loro set di test.<\/p>\n
Invece, dovremmo concentrarci sugli unit test e separare la nostra logica aziendale da WordPress.<\/p>\n
Ma non \u00e8 questo il punto di questo post. Invece, si tratta pi\u00f9 di un modo per presentare potenzialmente un progetto quando una parte di esso si interfaccer\u00e0 con WordPress.<\/p>\n
Ho parlato dell’importanza e dei vantaggi degli spazi dei nomi nei post precedenti in modo da non immergermi troppo in questa discussione qui.<\/p>\n
Invece, mi interessa parlare dell’organizzazione dei file a livello di filesystem e di namespace, in modo che siano nettamente separati nelle loro aree di specializzazione e cos\u00ec possiamo assicurarci di concentrare, diciamo, i nostri unit test (e altri test) sulle aree pi\u00f9 critiche.<\/p>\n
Mi piace assicurarmi che la mia directory e la struttura dei file rispecchino quella dei miei spazi dei nomi. Certo, aiuta con l’organizzazione dei file, ma anche con un’organizzazione concettuale.<\/p>\n
Cio\u00e8, se lavorer\u00f2 con meta box, so che probabilmente posso trovare i file meta box in una directory annidata con la directory principale di WordPress<\/strong>, quindi all’interno di una sottodirectory Admin<\/strong> seguita da una directory MetaBox<\/strong>.<\/p>\n A tal fine, come potrebbe essere un insieme di classi progettate per lavorare con i meta box, dovremmo scrivere il codice per loro in modo riutilizzabile? Dato quello che sappiamo sui meta box, sappiamo che probabilmente avremo bisogno di quanto segue:<\/p>\n Dati i punti precedenti, forse la struttura della directory sarebbe simile a questa:<\/p>\n<\/p>\n Successivamente, abbiamo un codice che rispecchia questa struttura. Cio\u00e8, all’interno della nostra directory di WordPress<\/strong>, avremmo la sottodirectory Admin<\/strong> poich\u00e9 la meta box viene visualizzata nell’area di amministrazione di WordPress e avremmo la sottodirectory View<\/strong> che conterrebbe il file responsabile della visualizzazione delle informazioni.<\/p>\n Questo ci lascia con la necessit\u00e0 di creare alcune classi come elencato sopra. Forse la classe base astratta sarebbe simile a questa:<\/a><\/strong><\/p>\n Quindi un’implementazione concreta estenderebbe la classe e assomiglierebbe a questa:<\/a><\/strong><\/p>\n E infine, la vista per la classe conterrebbe qualsiasi codice di markup e modello per il rendering delle informazioni<\/a><\/strong> :<\/p>\n Questo ci d\u00e0 esattamente ci\u00f2 di cui abbiamo bisogno in un modo ben organizzato e riutilizzabile per lavorare con i meta box. Pu\u00f2 anche essere ripetuto per cose come menu, tipi di post, tassonomie e cos\u00ec via.<\/p>\n Ma sto divagando.<\/p>\n Come accennato in precedenza nel post, credo che le classi di unit test che risolvono problemi unici nel nostro spazio problematico siano importanti. Ci\u00f2 significa che dovresti dire al tuo file di configurazione PHPUnit di escludere i tuoi file incentrati su WordPress.<\/p>\n Il vantaggio di ci\u00f2 che ho esposto sopra \u00e8 che questo diventa banalmente facile. In poche parole, puoi aggiungerlo<\/a><\/strong> al tuo file phpunit.xml<\/strong> :<\/p>\n Ci\u00f2 ti d\u00e0 la possibilit\u00e0 di concentrarti sulla scrittura di test specifici per il tuo spazio problematico assicurandoti allo stesso tempo di scrivere codice basato su WordPress scalabile, manutenibile e riutilizzabile.<\/p>\n Attualmente sto scrivendo un eBook (insieme a una variet\u00e0 di altri contenuti premium). Se sei interessato, controlla cosa ottieni<\/a>.<\/p>\n\n
<?php\n\nnamespace AcmeWordPressAdminMetaBox;\n\nabstract class AbstractMetaBox\n{\n protected $postType;\n\n public function __construct()\n {\n $this->postType = 'acme_post_type';\n }\n\n abstract public function render();\n abstract public function display();\n}\n<\/code><\/pre>\n<?php\n\nnamespace AcmeWordPressAdminMetaBox;\n\nclass AcmeMetaBox extends AbstractMetaBox\n{\n \/**\n * {@inheritdoc}\n *\/\n public function render()\n {\n add_meta_box(\n 'acme-product-image',\n 'Product Image',\n [$this, 'display'],\n $this->postType,\n 'side',\n 'default'\n );\n }\n\n \/**\n * {@inheritdoc}\n *\/\n public function display()\n {\n include_once plugin_dir_path(__FILE__).'Views\/acme-product-image.php';\n }\n}\n<\/code><\/pre>\n<div class=\"product-image-metabox\">\n <p>\n <img src=\"<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>\" alt=\"<?= esc_attr(get_the_title()); ?>\" \/>\n <input type=\"text\" value=\"<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>\" \/>\n <\/p>\n<\/div><\/code><\/pre>\nUna parola sui test unitari (con PHPUnit)<\/h3>\n
<testsuites>\n <testsuite name=\"Plugin\">\n <directory>.\/tests<\/directory>\n <exclude>.\/tests\/phpunit<\/exclude>\n <exclude>.\/src\/WordPress<\/exclude>\n <\/testsuite>\n<\/testsuites><\/code><\/pre>\n