Share
In het eerste bericht in deze serie bespraken we de redenen waarom WordPress-plug-ins meer als grotere softwareprojecten moeten worden behandeld (maar vaak niet) en pleiten voor een goed georganiseerde code in een poging onze plug-in-projecten beter onderhoudbaar te maken . Dit alles gebeurde in het kader van de ontwikkeling van een WordPress-widget.
Het punt is dat widgets niet het enige type plug-ins zijn dat voor WordPress kan worden ontwikkeld. De applicatie ondersteunt ook plug-ins die de functionaliteit uitbreiden door het gebruik van haken in de hele applicatie. Als zodanig zijn widgets niet het enige type plug-in dat baat zou kunnen hebben bij een boilerplate.
In deze zelfstudie definiëren we wat precies WordPress-hooks zijn, hoe ze werken en waarom ze nuttig zijn. Vervolgens zullen we mijn WordPress Widget Boilerplate bekijken en deze gebruiken in nieuwe projecten door de context van een voorbeeldtoepassing.
Voordat u plug-ins gaat ontwikkelen, is het belangrijk om het WordPress-model te kennen voor het inhaken in de toepassing en de verschillen tussen acties en filters.
Makkelijk genoeg, toch? Bovendien beschikt WordPress over gedegen documentatie voor het toevoegen van acties [1] en het toevoegen van filters [2]. U kunt veel meer bereiken over plug-ins in de plug-ins API [3] in de WordPress Codex [4].
Als u het vorige artikel leest, bent u al bekend met de widget-API. Het is precies omdat het een constructor en niet minder dan drie functies vereist om iets te laten werken. Omdat plug-ins de flexibiliteit hebben om op verschillende punten in het WordPress-proces te haken, is de Plugin-API iets minder gestructureerd. Gelukkig betekent dit niet dat we geen enkele vorm van boilerplate kunnen maken om onze plug-ins te maken.
Ze bestaan immers nog steeds uit een aantal veel voorkomende functies:
Net als bij onze WordPress Widget Boilerplate, kunnen we onze template directory zo instellen:
Lijkt bekend, toch? Het belangrijkste aspect van de Plugin Boilerplate is niet de details van de directorystructuur (hoewel we in de toekomst een beetje zullen onderzoeken), maar de organisatie van de plugincode zelf.
Plug-ins kunnen worden ontwikkeld door een handvol functies te gebruiken of door elke functie in een klasse in een objectgerichte benadering in te pakken. Ik ben een fan van de laatste en mijn boilerplate vertegenwoordigt dat. Dit is de definitie van de plug-in:
Accentsconagua
init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, dirname (plugin_basename (__ FILE__)). '/ lang'); / * * TODO: * Definieer de aangepaste functionaliteit voor uw plug-in. De eerste parameter van de * add_action / add_filter-oproepen zijn de hooks waarin uw code moet worden geactiveerd. * * De tweede parameter is de functienaam die zich in deze klasse bevindt. Zie de stubs * later in het bestand. * * Voor meer informatie: * http://codex.wordpress.org/Plugin_API#Hooks.2C_Actions_and_Filters * / add_action ('TODO', array ($ this, 'action_method_name')); add_filter ('TODO', array ($ this, 'filter_method_name')); // end if // end constructor / * -------------------------------------- ------* * Kernfuncties *--------------------------------------- ------ * / / ** * Opmerking: Acties zijn punten bij het uitvoeren van een pagina of proces * lifecycle waarop WordPress wordt geactiveerd. * / function action_method_name () // TODO definieer hier uw actiemethode // end action_method_name / ** * Opmerking: Filters zijn uitvoeringspunten waarin WordPress gegevens * wijzigt voordat deze worden opgeslagen of naar de browser worden verzonden. * / function filter_method_name () // definieer hier uw filtermethode // end filter_method_name / * ---------------------------- ---------------- * * Privéfuncties * ----------------------------- ---------------- * / / ** * Initialiseert constanten die gedurende het hele gebruiksgemak worden gebruikt * de plug-in. * / private function init_plugin_constants () / * TODO * * Dit biedt de unieke identificatie voor uw plug-in die wordt gebruikt bij * het lokaliseren van de strings die overal worden gebruikt. * * Bijvoorbeeld: wordpress-widget-boilerplate-locale. * / if (! define ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'plugin-name-locale'); // end if / * TODO * * Definieer dit als de naam van uw plug-in. Dit is wat * laat zien in het gebied Widgets van WordPress. * * Bijvoorbeeld: WordPress Widget Boilerplate. * / if (! define ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'Plugin Name'); // end if / * TODO * * dit is de slug van uw plug-in die wordt gebruikt bij het initialiseren met * de WordPress API. * Dit zou ook de * directory moeten zijn waarin uw plug-in zich bevindt. Gebruik koppeltekens. * * Bijvoorbeeld: wordpress-widget-boilerplate * / if (! Defined ('PLUGIN_SLUG')) define ('PLUGIN_SLUG', 'plugin-name-slug'); // end if // end init_plugin_constants / ** * Helper-functie voor het registreren en laden van scripts en stijlen. * * @name De ID om te registreren bij WordPress * @file_path Het pad naar het eigenlijke bestand * @is_script Optioneel argument voor als het binnenkomende bestandspad een JavaScript-bronbestand is. * / persoonlijke functie load_file ($ name, $ file_path, $ is_script = false) $ url = WP_PLUGIN_URL. $ FILE_PATH; $ file = WP_PLUGIN_DIR. $ FILE_PATH; if (file_exists ($ file)) if ($ is_script) wp_register_script ($ name, $ url); wp_enqueue_script ($ name); else wp_register_style ($ name, $ url); wp_enqueue_style ($ name); // end if // end if // end _load_file // end class // TODO: werk de instantiatiereis van uw plug-in bij naar de naam die is opgegeven bij de klassendefinitie nieuwe TODO (); ?> De meeste IDE's hebben een functie die alle uitstaande TODO's weergeeft, dus plaats ik ze in de hele code om eenvoudig te vinden wat er tijdens de ontwikkeling moet gebeuren. Merk op dat er drie primaire codegebieden zijn:
Merk op dat de ontwikkeling van plug-ins afwijkt van widget-ontwikkeling in de zin dat er niet meerdere functies worden verwacht. Eigenlijk heb je eigenlijk alleen een constructeur nodig. Vanaf daar zijn alle functies gedefinieerd in de add_action of add_filter-oproepen en uw verantwoordelijkheid om te implementeren.
Heb je zin? Laten we eens kijken naar het gebruik van deze ketelplaat in een eenvoudig voorbeeld.
WordPress biedt haken voor bijna het punt van uitvoering die je je kunt voorstellen. In dit voorbeeld nemen we deel aan het post-renderingproces om een aangepast bericht te introduceren. Het punt is dat we het bericht alleen in de context van een RSS-lezer willen weergeven.
Ten eerste, de vereisten:
Op basis hiervan lijkt het erop dat we geen JavaScript, CSS of markup nodig hebben om onze plug-in te maken, zodat we onze plugin-boilerplate kunnen herleiden tot de plug-in code en de lokalisatiebestanden:
Op dit punt kunnen we beginnen met het uitzetten van de boilerplate met een naam en de plug-ins constanten:
/ ** * Initialiseert constante constanten * in de plug-in. * / private functie init_plugin_constants () if (! defined ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'rss-note-locale'); // end if if (! define ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'RSS Note'); // end if if (! defined ('PLUGIN_SLUG')) define ('PLUGIN_SLUG', 'rss-note-slug'); // end if // end init_plugin_constants beëindigen Vervolgens moeten we overwegen welk type haak nodig is om de inhoud te manipuleren. Denk eraan dat we proberen iets aan de inhoud toe te voegen om het in de browser weer te geven, we hebben een filter nodig. Vanaf hier kunnen we de constructor stubben:
/ ** * Initialiseert de plug-in door localisatie, filters en beheerfuncties in te stellen. * / function __construct () // Definieer constnats die worden gebruikt in de hele plugin $ this-> init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, dirname (plugin_basename (__ FILE__)). '/ lang'); // voeg de notitie toe aan zowel het fragment als de hoofdfeed add_filter ('the_content', array ($ this, 'display_rss_note')); add_filter ('the_excerpt_rss', array ($ this, 'display_rss_note')); // eindconstructor Merk op dat de functie twee filters gebruikt: één voor the_content [5] en één voor the_excerpt_rss [6]. We doen dit omdat sommige gebruikers ervoor kiezen om alleen een fragment van hun blog te publiceren in plaats van alle inhoud en we willen ervoor zorgen dat we beide gevallen vastleggen.
Laten we vervolgens de functiedefinitie die het bericht aan de rest van het bericht toevoegt, daadwerkelijk implementeren:
/ ** * Voegt een kort bericht toe aan het begin van elk bericht in een RSS-lezer * om gebruikers eraan te herinneren uw website te bezoeken. * / openbare functie display_rss_note ($ content) if (is_feed ()) $ content. = ''; $ content. = ''; // einde als return $ inhoud; // einde display_rss_note'; $ content. = __ ('Bedankt voor het lezen! Zorg ervoor dat je de rest van mijn berichten inhaalt bij', PLUGIN_LOCALE); $ content. = ''; $ content. = get_bloginfo ('naam'); $ content. = '!'; $ content. = '
'; $ content. = '
Merk op dat de functie een parameter accepteert waarnaar de $ inhoudvariabele verwijst. WordPress zelf geeft deze gegevens door aan de functie. Voor deze specifieke filters hebben we te maken met de inhoud van een blogpost, dus alles wat we toevoegen, moet worden samengevoegd zodat het wordt toegevoegd aan het einde ervan.
Dit bericht dat we toevoegen, zegt simpelweg "Bedankt voor het lezen! Zorg ervoor dat je de rest van mijn berichten bij [Blognaam] hebt ingehaald!" door gebruik te maken van de functie get_bloginfo () [7]? Je kunt het natuurlijk updaten om te lezen wat je maar wilt. Merk ten slotte op dat we dit hebben ingepakt in een voorwaarde die de functie is_feed () [8] controleert. Dit is belangrijk omdat we alleen willen dat deze code wordt geactiveerd als de inhoud via een RSS-feed wordt verzonden.
Dat is alles - niet slecht, toch? Je kunt de volledige versie van de werkende broncode (inclusief de bijbehorende README) voor deze plug-in downloaden op GitHub of hier bij Wptuts. De boilerplate is ook beschikbaar op GitHub.
Het doel van deze serie was niet alleen om een inleidende handleiding voor de WordPress Plugin-API te bieden, maar ook om een case en boilerplates te bieden om het veel gemakkelijker te maken en te onderhouden met WordPress-plug-ins zoals elk ander softwareproject.
