Share
Velkommen til siste del av denne serien. Hvis du nettopp ankom, vennligst sjekk våre to tidligere artikler. Vi har så langt dekket følgende emner:
Tips for beste praksis i WordPress Development
Flere tips for beste praksis i WordPress Development
I denne siste artikkelen skal jeg snakke om tre viktige ting, selv om de ikke påvirker plugin-operasjonen, er de avgjørende hvis du vil levere en kvalitetstillegg.
Det første du bør gjøre når du kodes et plugin, er å aktivere feilsøkingsmodussom WordPress anbefaler. På den måten ser du alle feil, advarsler og problemer.
For å aktivere feilsøkingsmodus enkelt sted i din wp-config.php
Accentsconagua
define ('WP_DEBUG', true);Når du har lastet opp siden, vil du se alle advarsler og problemer sammen med andre meldinger som avviklet WordPress-funksjoner. Hvis du vil levere et kvalitetsprodukt, må du kontrollere at ved hjelp av pluginet med feilsøkingsmodus aktiveres eller deaktiveres resultatet i det samme (ingen feil, advarsler eller merknader i det hele tatt).
Hvis du i stedet vil lagre feilene i en fil og ikke vise dem i HTML-en, kan du gjøre det ved å legge sammen med WP_DEBUG følgende linjer.
// alle feilene vil bli lagret i en debug.log loggfil inne i / wp-content / directory definere ('WP_DEBUG_LOG', true); // ikke vise feil i HTML definere ('WP_DEBUG_DISPLAY', falsk);En annen feilsøkingsinnstilling som jeg bruker mye som lagrer alle databasespørsmål i en matrise er følgende:
define ('SAVEQUERIES', true);Vanligvis bruker jeg alle disse (spesielt den siste) med Debug Bar plugin og Debug Bar konsoll. Hvis du ikke kjenner dem, kan du gå og ta en kopi og begynne å feilsøke pluginene og temaene dine. Du vil se hvor lett det er å gjøre det.
Du kan også sjekke lister over plugins jeg bruker til utvikling i Wp Favs.
Dokumentere alle aspekter av plugin eller tema vil gjøre brukerne og livet ditt mye enklere. De vil være i stand til å lage plugin eller tema arbeid ved å følge en guide eller video eller en kombinasjon av begge og du vil spare mye tid med støtte billetter og endeløse e-poster.
Jeg anbefaler å dele all dokumentasjon i kategorier eller seksjoner som er viktigst:
Deretter kan du legge til resten av seksjoner eller kategorier, avhengig av tema eller plugin. Hvis du sjekker dokumentasjonssiden for WordPress Social Invitasjoner, vil du se hva jeg mener.
Hvis du la til filtre og kroker som jeg nevnte i forrige artikkel, er det en god ide å lage en filter / handling referanseside som forklarer hva de gjør.
Hjelpfaner er en annen måte å gi brukerne direkte hjelp til pluginet ditt, i stedet for å omdirigere dem til nettstedet ditt. De brukes normalt til å gi informasjon om at skjermen er i bruk i det øyeblikket.
For eksempel, på en av mine plugin kalt Social PopUP bruker jeg en hjelpefane for å forklare de tilgjengelige kortkodene.
Hvis du bruker en klasse i pluginet ditt og du vil legge til hjelpefanen til en egendefinert innleggstype, kan du gjøre noe som helst:
/ ** * Initialiser pluginet ved å laste inn adminskript og stiler og legge til en * innstillingsside og -meny. * * @since 1.0.0 * / function __construct () [...] // Hjelp Tab add_action ('load-post.php', array ($ dette, 'my_admin_add_help_tab'))); / ** * Legg til hjelpefane til spucpt-posttypen * @since 1.0 * @return void * / function my_admin_add_help_tab () $ screen = get_current_screen (); hvis ('spucpt'! = $ skjerm-> id) return; // Legg til my_help_tab hvis posttype er spucpt $ screen-> add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Shortcodes'), 'content' => 'Hei innhold går her' ,)); Det er veldig viktig at du kontrollerer at gjeldende skjerm-ID samsvarer med egendefinert innleggstype eller hjelpefanen vises overalt.
Hvis du i stedet la til en tilleggsside, kan du bruke koden som brukes som eksempel i Codex.
add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Min Hjelp-fanen'), 'content' => ''. __ ('Beskrivende innhold som vil vises i Min Hjelp-tabulator går her.'). '
',)); ?>I min mening er hjelpeflikene ikke veldig synlige for brukerne, og de fleste av dem vet ikke engang at de eksisterer, men det er en god praksis å inkludere noen hjelpelinjer i selve plugin-modulen..
Internationalisering også kjent som i18n (det er 18 bokstaver mellom i og n) det er glasur på kaken av et plugin eller tema. Som du allerede vet WordPress, brukes den av folk fra hele verden, så når du leverer et plugin eller tema, må vi være sikre på at de lett kan oversette det til morsmålet.
Først bør vi lære betydningen av disse to ordene også kjent som i18n og i10n. Internasjonalisering refererer til prosessen med å lage en oversetterbar plugin eller et tema mens lokalisering er i utgangspunktet handlingen med å gjøre det.
WordPress bruker det berømte gettext-biblioteket som forklart med noen få ord, vi kan si som fungerer slik:
Det første du må gjøre er å bestemme en tekst-domene som vil bli brukt til å pakke inn alle pluginene dine eller temaoversettelsene. Tekstdomenet bør samsvare med plugin-sluggen din.
Det er flere måter å opprette de translaterbare strengene avhengig av om du lager variabler, ekko noe osv. De vanligste funksjonene er __ () og _e () . La oss se noen eksempler nedenfor:
// skape en variabel $ hei = __ ('Hei, jeg er en oversettbar streng', 'My-text-domain'); ekko ''. __ ('Hei, jeg er en oversettbar streng', 'my-text-domain'). '
'; // for å gjøre et ekko du kan bruke _e ('Hei, jeg er en oversettbar streng', 'min-tekst-domene'); // Når du har variabler i strengen du gjør: printf (__ ('Vi slettet% d innlegg', 'my-text-domain'), $ telle); // Eller flere variabler printf (__ ('Ditt navn er% 1 $ s, og etternavnet ditt er% 2 $ s.', 'My-text-domene'), $ navn, $ etternavn);En annen kul funksjon som du kan bruke er _n () som det brukes til flertall. Disse funksjonene tar 4 argumenter:
Kommer tilbake til vårt forrige eksempel, med plurals vil se noe ut som:
printf (_n ('Vi slettet ett innlegg.', 'Vi slettet% d innlegg.', $ count, 'my-text-domain'), $ count);Hvis du, uansett, må oversette strenger i JavaScript, kan du passere alle strengene ved å bruke wp_localize_script () funksjon som vi diskuterte på den andre artikkelen i denne serien.
wp_enqueue_script ('script-handle', ...); wp_localize_script ('script-handle', 'objectL10n', array ('alert' => __ (' Dette er en varselmelding ',' my-text-domain '),' submit '=> __ (' Send ' mitt-tekst-domene '),));Vi har allerede lagt til alle oversetterbare strengene rundt plugin-modulen vår og nå er det på tide å aktivere det. For å gjøre det gjør du enkelt:
funksjon myplugin_init () $ plugin_dir = basename (dirname (__FILE__)); load_plugin_textdomain ('my-text-domain', false, $ plugin_dir); add_action ('plugins_loaded', 'myplugin_init');Dette stykke kode vil prøve å laste fra roten til plugin-en din MO-fil my-tekst-domene- Lokalitet.mo . Avhengig av språkinnstillingene i wp-config.php, erstattes locale -delen med språkkoden. For eksempel hvis min wp-config.php er konfigurert som:
define ('WPLANG', 'es_ES');Filen som skal lastes er my-text-domain-es_ES.mo. For temaer er ganske lik, trenger du bare å inkludere i din functions.php følgende:
load_theme_textdomain ('my_theme_textdomain');De hovedforskjell er at denne funksjonen vil se etter Lokalitet .mo i stedet for my_theme_textdomain- lokalitet .mo som vi så på forrige eksempel.
Du kan lese mer om l18n i WordPress Codex.
Vi er på slutten av denne serien, og jeg håper du likte å lese den så mye som jeg skrev det. Som jeg sa tidligere skrev jeg denne serien og tenkte på min begynnelse som utvikler. Jeg prøvde å samle all informasjonen som jeg anser viktig for å gjøre en god plugin, som i stor grad oppsummerer alt det som allerede er forklart i Codex. Selv om jeg nok har sluppet ut mye, tror jeg det er nok å ha solid grunnlag.
Jeg vil gjerne se deg dele dine tanker, tips og ideer for en solid utvikling i kommentarene.
