Schrijfbare WordPress Widgets schrijven deel 2 van 2

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.


Haken, acties en filters begrijpen

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.

  • Hooks zijn gedeelten in de kernapplicatie van WordPress waarmee u uw code kunt registreren voor uitvoering. Eenvoudig gezegd registreert uw plug-in zichzelf bij WordPress op een specifiek punt van uitvoering. Wanneer WordPress dat punt van uitvoering bereikt (bij het opslaan van informatie, het weergeven van informatie of een ander punt), wordt uw code geactiveerd.
  • Acties zijn een type haak dat WordPress voor u beschikbaar maakt om te profiteren van wanneer een specifieke gebeurtenis optreedt tijdens de levenscyclus van de toepassing. Sommige van deze punten omvatten wanneer een thema wordt geactiveerd, wanneer een bericht wordt opgeslagen, of wanneer stijlbladen worden weergegeven. Over het algemeen is het waarschijnlijk dat er een actiehaak beschikbaar is als u op enig moment in de WordPress-levenscyclus een soort aangepaste functionaliteit wilt invoegen..
  • Filters zijn een type haak dat WordPress voor u beschikbaar maakt om gegevens te manipuleren voordat het naar de database wordt verzonden of om het in de browser te renderen. Simpel gezegd, WordPress geeft de inhoud door aan uw functie en gaat vervolgens door met het proces met alles wat u terugkrijgt. Als u gegevens wilt manipuleren voordat u deze opslaat of bekijkt, is de beste optie om filter te gebruiken.

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].


Een plug-in ketelplaat

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:

  • Core plugin-code
  • Stijlbladen
  • JavaScript
  • Lokalisatiebestanden
  • markup
  • Afbeeldingen

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.

Het pluginskelet

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:

 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:

  1. Constructor. Deze functie is verantwoordelijk voor het definiëren van alle constanten die door de code worden gebruikt, specificeert eventuele lokaliseringsbestanden en registreert alle acties en filters met WordPress.
  2. Kernfuncties zijn de feitelijke functiedefinities die zijn geregistreerd in de constructor en die worden afgevuurd na de uitvoering van WordPress.
  3. Helperfuncties verwijzen naar functies die ik gebruik die helpen bij het uitvoeren door veelgebruikte functies te abstraheren (zoals het registreren van JavaScripts en stylesheets).

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.


Een werkvoorbeeld met de RSS-feed van uw blog

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:

  • Geef een bericht weer aan het begin van elk bericht
  • Het bericht zou alleen in RSS-readers moeten verschijnen
  • Het bericht zou een link moeten bevatten naar de website van de post

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. = '

'; $ 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. = '
'; // einde als return $ inhoud; // einde display_rss_note

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.

  1. http://codex.wordpress.org/Function_Reference/add_action
  2. http://codex.wordpress.org/Function_Reference/add_filter
  3. http://codex.wordpress.org/Plugin_API
  4. http://codex.wordpress.org/Main_Page
  5. http://codex.wordpress.org/Function_Reference/the_content
  6. http://codex.wordpress.org/Template_Tags/the_excerpt_rss
  7. http://codex.wordpress.org/Function_Reference/is_feed
  8. http://codex.wordpress.org/Function_Reference/get_bloginfo