Share
Welkom bij het laatste deel van deze serie. Als je net bent aangekomen, bekijk dan onze twee eerdere artikelen. We hebben tot nu toe de volgende onderwerpen behandeld:
Tips voor beste praktijken in WordPress Development
Meer tips voor beste praktijken in WordPress Development
In dit laatste artikel ga ik het hebben over drie belangrijke zaken die, hoewel ze geen invloed hebben op de werking van de plug-in, essentieel zijn als je een kwaliteitsplugin wilt leveren.
Het eerste dat u moet doen tijdens het coderen van een plug-in, is om de foutopsporingsmodus in te schakelenzoals WordPress aanbeveelt. Op die manier ziet u alle fouten, waarschuwingen en problemen.
Om foutopsporingsmodus eenvoudig in te schakelen in uw wp-config.php
Accentsconagua
define ('WP_DEBUG', true);Zodra u de site opnieuw laadt, ziet u alle waarschuwingen en problemen samen met andere berichten zoals verouderde WordPress-functies. Als u een kwaliteitsproduct wilt leveren, zorg er dan voor dat het gebruik van uw plug-in met de debug-modus in- of uitschakelen resulteert in hetzelfde (geen fouten, waarschuwingen of mededelingen).
Als u in plaats daarvan de fouten in een bestand wilt opslaan en ze niet in de HTML wilt weergeven, kunt u dit doen door samen met te voegen WP_DEBUG de volgende regels.
// alle fouten worden opgeslagen in een debug.log-logboekbestand in de / wp-content / directory define ('WP_DEBUG_LOG', true); // niet weergavefouten in HTML define ('WP_DEBUG_DISPLAY', false);Een andere foutopsporingsinstelling die ik veel gebruik om alle databasequery's in een array op te slaan, is de volgende:
define ('SAVEQUERIES', true);Meestal gebruik ik al deze (met name de laatste) met de plug-in Debug Bar en de Debug Bar-console. Als je ze niet kent, neem dan een kopie en begin met het debuggen van je plug-ins en thema's. Je zult zien hoe gemakkelijk het is om het te doen.
Je kunt ook de lijst met plug-ins controleren die ik gebruik voor ontwikkeling in Wp Favs.
Het documenteren van elk aspect van uw plug-in of thema maakt uw gebruikers en uw leven veel gemakkelijker. Ze zullen in staat zijn om de plug-in of het thema te laten werken door een gids of video of een combinatie van beide te volgen en je zult veel tijd besparen met support tickets en eindeloze e-mails.
Ik raad aan om alle documentatie op te splitsen in categorieën of secties die het belangrijkst zijn:
Afhankelijk van uw thema of plug-in kunt u de rest van secties of categorieën toevoegen. Als je de documentatiepagina van WordPress Social Invitations bekijkt, zul je zien wat ik bedoel.
Als je filters en hooks hebt toegevoegd zoals ik in het vorige artikel heb genoemd, is het een goed idee om een filter- / acties-verwijzingspagina te maken met uitleg over wat ze doen.
Help-tabbladen zijn een andere manier om uw gebruikers rechtstreeks op uw plug-in te helpen, in plaats van ze door te sturen naar uw website. Ze worden normaal gesproken gebruikt om informatie te geven over het scherm dat op dat moment wordt gebruikt.
Bijvoorbeeld, op een van mijn plug-ins genaamd Social PopUP gebruik ik een help-tabblad om de beschikbare shortcodes uit te leggen.
Als u een klasse in uw plug-in gebruikt en u het help-tabblad wilt toevoegen aan een aangepast berichttype, kunt u iets doen als:
/ ** * Initialiseer de plug-in door admin-scripts & -stijlen te laden en een * instellingenpagina en -menu toe te voegen. * * @since 1.0.0 * / function __construct () [...] // Help Tab add_action ('load-post.php', array ($ this, 'my_admin_add_help_tab')); / ** * Help-tabblad toevoegen aan het type spucpt-bericht * @since 1.0 * @return void * / function my_admin_add_help_tab () $ screen = get_current_screen (); if ('spucpt'! = $ screen-> id) return; // Add my_help_tab als berichttype spucpt is $ screen-> add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Shortcodes'), 'content' => 'Hallo inhoud komt hier' ,)); Het is erg belangrijk dat u controleert of de huidige scherm-ID overeenkomt met uw aangepaste berichttype of dat het Help-tabblad overal wordt weergegeven.
Als u in plaats daarvan een optiepagina hebt toegevoegd, kunt u de code gebruiken die als voorbeeld wordt gebruikt in de Codex.
add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Mijn Help-tabblad'), 'content' => ''. __ ('Beschrijvende inhoud die wordt weergegeven in het tabblad' Mijn hulp 'komt hier.'). '
',)); ?>Naar mijn mening zijn helptabbladen niet erg zichtbaar voor gebruikers, en de meeste van hen weten niet eens dat ze bestaan, maar het is een goede gewoonte om een aantal hulplijnen in de plug-in zelf op te nemen.
Internationalisering ook bekend als i18n (er zijn 18 letters tussen de i en de n) het is de kers op de taart van een plug-in of een thema. Zoals je WordPress al kent, wordt het gebruikt door mensen van over de hele wereld, dus op het moment dat een plug-in of thema wordt geleverd, moeten we zeker weten dat ze het gemakkelijk in hun moedertaal kunnen vertalen.
Ten eerste moeten we leren wat de betekenis van deze twee woorden ook is i18n en i10n. Internationalisering verwijst naar het proces van het maken van een vertaalbare plug-in of een thema, terwijl lokalisatie in feite de handeling van het doen is.
WordPress maakt gebruik van de beroemde gettext-bibliotheek die in een paar woorden is uitgelegd, we kunnen zeggen dat dit zo werkt:
Het eerste dat u hoeft te doen, is een beslissing nemen text-domein die zal worden gebruikt om al uw plug-in of themavertalingen in te pakken. Het tekstdomein moet overeenkomen met uw plugin-slug.
Er zijn meerdere manieren om de vertaalbare reeksen te maken, afhankelijk van of u variabelen aanmaakt, iets echoot, enz. De meest voorkomende functies zijn __ () en _e () . Laten we een paar voorbeelden hieronder bekijken:
// een variabele maken $ hello = __ ('Hallo, ik ben een vertaalbare tekenreeks', 'mijn-tekst-domein'); echo ''. __ ('Hallo, ik ben een vertaalbare tekenreeks', 'mijn-tekst-domein'). '
'; // om een echo uit te voeren, kunt u _e gebruiken ('Hallo, ik ben een vertaalbare tekenreeks', 'mijn-tekst-domein'); // Wanneer u variabelen in de reeks hebt die u doet: printf (__ ('We hebben% d berichten verwijderd', 'mijn-tekst-domein'), $ aantal); // Of meerdere variabelen printf (__ ('Uw naam is% 1 $ s, en uw achternaam is% 2 $ s.', 'Mijn-tekst-domein'), $ naam, $ achternaam);Een andere coole functie die je kunt gebruiken is _n () waarvan het wordt gebruikt voor meervoudsvormen. Deze functie heeft 4 argumenten nodig:
Terugkomend op ons vorige voorbeeld, met meervoudsvormen ziet het er ongeveer zo uit:
printf (_n ('We hebben een bericht verwijderd', 'We hebben% d berichten verwijderd', $ count, 'mijn-tekst-domein'), $ aantal);Als je toevallig strings in je JavaScript moet vertalen, kun je alle reeksen doorgeven met behulp van de wp_localize_script () functie die we hebben besproken in het tweede artikel van deze serie.
wp_enqueue_script ('script-handle', ...); wp_localize_script ('script-handle', 'objectL10n', array ('alert' => __ ('Dit is een waarschuwingsbericht', 'mijn-tekst-domein'), 'submit' => __ ('Verzenden', ' my-text-domain '),));We hebben al de translatable string rond onze plugin toegevoegd en nu is het tijd om het in te schakelen. Om dat te doen doe je simpel:
function myplugin_init () $ plugin_dir = basenaam (dirname (__FILE__)); load_plugin_textdomain ('mijn-tekst-domein', false, $ plugin_dir); add_action ('plugins_loaded', 'myplugin_init');Dit stukje code zal proberen om vanuit de root van je plugin een MO-bestand genaamd mijn-text-domein-Locale.mo . Afhankelijk van uw taalinstellingen in wp-config.php, wordt het gedeelte locale vervangen door uw taalcode. Bijvoorbeeld als mijn wp-config.php is geconfigureerd als:
define ('WPLANG', 'es_ES');Het bestand dat wordt geladen is my-text-domain-es_ES.mo. Voor thema's is vergelijkbaar, je hoeft alleen op te nemen in uw functions.php het volgende:
load_theme_textdomain ('my_theme_textdomain');De grootste verschil is dat deze functie zal zoeken Locale .mo in plaats van my_theme_textdomain- locale .mo zoals we in het vorige voorbeeld zagen.
U kunt meer lezen over l18n in de WordPress Codex.
We zijn aan het einde van deze serie en ik hoop dat je het net zo leuk vond om het te lezen als ik het heb geschreven. Zoals ik al eerder zei, heb ik deze serie geschreven, denkend aan mijn begin als ontwikkelaar. Ik heb geprobeerd om alle informatie te verzamelen die ik belangrijk vind om een goede plug-in te maken, en op grote schaal een samenvatting te geven van wat het al in de Codex heeft uitgelegd. Hoewel ik waarschijnlijk veel heb weggelaten, denk ik dat het voldoende is om een solide basis te hebben.
Ik zou het leuk vinden als je je gedachten, tips en ideeën deelt voor een gedegen ontwikkeling in de opmerkingen.
