Lag en enkel CRM i WordPress Utvidelse av WordPress Search

Vi har sett på hvordan du lager et enkelt CRM-system i WordPress. I den siste delen av denne serien la vi til kode i pluginet vårt som tillot oss å vise våre avanserte egendefinerte felt i WordPress List Table (WP_List_Table), og sortere dataene våre alfabetisk av de nye feltene.

I dag skal vi dekke hvordan du utvider søkefunksjonaliteten for å inkludere dataene som er lagret i våre egendefinerte felt.

Søk Funksjonalitet

Hver posttype som har et administrasjonsgrensesnitt, kommer med en søkeboks:

Som standard, når en bruker søker etter Post (e) i WordPress Administration grensesnittet, vil WordPress søke i wp_posts tabell for å finne noen delvise innholdskomponenter på tvers av følgende felt:

  • Tittel
  • Innhold
  • Utdrag

Hvis vi prøver å søke etter et delvis telefonnummer, ser vi at ingen resultater vises:

For vår Contact Custom Post Type, er dette ikke veldig nyttig hvis vi vil finne en kontakt via telefonnummer eller e-postadresse!

Advanced Custom Fields lagrer dataene sine i wp_postmeta tabell, som WordPress ikke søker som standard. Vi trenger å bruke to av WordPress som tilbys filtre for å tillate WordPress søkefunksjonalitet også å søke i avanserte tilpassede feltdata. Disse filtrene vil:

  1. utfør en SQL JOIN mellom WordPress Post Meta-tabellen og WordPress Posts-tabellen
  2. legg til en SQL WHERE-klausul i WordPress Post Query for å søke i vårt WordPress Posts Meta-tabellen

Utføre en SQL JOIN

La oss begynne med å legge til posts_join filtrer til vår plugin class konstruksjon for å bli med i WordPress:

/ ** * Constructor. Kalt når plugin er initialisert * / funksjon __construct () add_action ('init', array (& $ this, 'register_custom_post_type')); add_action ('plugins_loaded', array (& $ dette, 'acf_fields')); add_filter ('manage_edit-contact_columns', array (& $ dette, 'add_table_columns')); add_action ('manage_contact_posts_custom_column', array (& $ dette, 'output_table_columns_data'), 10, 2); add_filter ('manage_edit-contact_sortable_columns', array (& $ dette, 'define_sortable_table_columns')); hvis (is_admin ()) add_filter ('request', array (& $ this, 'orderby_sortable_table_columns')); add_filter ('posts_join', array (& $ dette, 'search_meta_data_join'));  

Vi må også definere vår search_meta_data_join () funksjon, som forteller WordPress hvilken tabell vi ønsker å bli med i WordPress Posts hovedtabell:

/ ** * Legger til en tilmelding til WordPress-metatabellen for lisensnøkkel-søk i WordPress-administrasjonen * * @param-strengen $ delta i SQL JOIN-setningen * @returnstreng SQL JOIN-setningen * / funksjon search_meta_data_join ($ join) global $ wpdb; // Bare bli med i postmetabellen hvis vi utfører et søk hvis (tomt (get_query_var ('s'))) return $ join;  // Bare bli med i post-metatabellen hvis vi er på Kontakter tilpasset posttype hvis ('kontakt'! = Get_query_var ('post_type')) return $ join;  // Bli med på postmetabellen $ join. = "VENSTRE BLI MED $ wpdb-> postmeta ON $ wpdb-> posts.ID = $ wpdb-> postmeta.post_id"; returner $ join;  

get_query_var () er en funksjon som returnerer den aktuelle spørringsvariabelen som er lagret i WP_Query klasse. WP_Query er en WordPress-klasse som gir:

... informasjon som definerer den nåværende forespørselen ... hvilken type spørring det handler om (muligens et kategoriarkiv, datert arkiv, feed eller søk), og henter de etterspurte innleggene. Den beholder mye informasjon på forespørselen, som kan trekkes på et senere tidspunkt.

get_query_var () er den magien som lar oss "trekke" den informasjonen. I dette tilfellet kontrollerer vi spørringsvariabelen 'S', forteller oss hvilket søkeord (hvis noe) brukeren har bedt om. Vi bruker også denne samme funksjonen til å kontrollere hvilken posttype (e) brukeren ber om - vi ønsker bare å utvide søket hvis brukeren ser på Kontakt tilpasset posttype.

Hvis disse betingelsene er oppfylt, blir vi med i wp_postmeta bord til hoveddelen wp_posts bord.

$ wpdb brukes også her, og det er en definert klasse som:

... inneholder et sett med funksjoner som brukes til å samhandle med en database. Hovedformålet er å gi et grensesnitt med WordPress-databasen, men kan brukes til å kommunisere med andre relevante databaser.

Kort oppsummert, $ wpdb Lar oss få tilgang til MySQL-databasen, få konfigurasjonsinnstillinger og utføre SQL-spørringer.

I dette tilfellet bruker vi $ wpdb for å få navnene på post- og postmetabordene, fordi disse kan modifiseres av hver WordPress-installasjon. For eksempel kan en installasjon sette sitt prefiks for tabellnavn til wp_ (som er standard), mens en annen installasjon kan sette den til my_awesome_site_. Vi kan ikke hardt kode tabellnavn, som vi ikke kan garantere at de alltid vil være wp_posts og wp_postmeta, så vi bruker $ Wpdb-> innlegg og $ Wpdb-> postmeta, som inneholder de faktiske tabellnavnene som er spesifikke for denne WordPress-installasjonen.

Legger til SQL WHERE-klausulen

Med vår SQL JOIN-komplett, må vi nå fortelle WordPress å søke i det medfølgende Post Meta-tabellen.

Gå tilbake til pluginens __construct (), og legg til en ny funksjon til posts_where filter:

/ ** * Constructor. Kalt når plugin er initialisert * / funksjon __construct () add_action ('init', array (& $ this, 'register_custom_post_type')); add_action ('plugins_loaded', array (& $ dette, 'acf_fields')); add_filter ('manage_edit-contact_columns', array (& $ dette, 'add_table_columns')); add_action ('manage_contact_posts_custom_column', array (& $ dette, 'output_table_columns_data'), 10, 2); add_filter ('manage_edit-contact_sortable_columns', array (& $ dette, 'define_sortable_table_columns')); hvis (is_admin ()) add_filter ('request', array (& $ this, 'orderby_sortable_table_columns')); add_filter ('posts_join', array (& $ dette, 'search_meta_data_join')); add_filter ('posts_where', array (& $ this, 'search_meta_data_where'));  

Vi må også definere vår search_meta_data_where () funksjon, som forteller WordPress å søke på Post Meta data:

/ ** * Legger til en hvor klausul til WordPress meta-tabellen for lisensnøkkel søk i WordPress-administrasjonen * * @param string $ der SQL WHERE-setningen * @returnstrengen SQL WHERE-klausuler * / funksjon search_meta_data_where ($ where)  global $ wpdb; // Bare bli med i postmetabellen hvis vi utfører et søk hvis (tomt (get_query_var (s ')))) return $ where;  // Bare bli med i postmetabasen hvis vi er på Kontakter tilpasset posttype hvis ('kontakt'! = Get_query_var ('post_type')) return $ where;  // Få starten på spørringen, som er 'OG ((' og resten av spørringen $ startOfQuery = substr ($ hvor, 0, 7); $ restOfQuery = substr ($ hvor, 7); // Injiser våre WHERE-klausuler mellom start av spørringen og resten av spørringen $ where = $ startOfQuery. "(". $ Wpdb-> postmeta. ".Meta_value LIKE '%". Get_query_var (s). " "OR". $ RestOfQuery. "GROUP BY". $ Wpdb-> innlegg. ".Id"; // Retur revidert WHERE-setningen returnerer $ where; 

På samme måte som vi gjorde i search_meta_data_join (), Vi kontrollerer igjen at WordPress Query er et søk på Kontakter tilpasset posttype. Hvis ikke, returnerer vi $ mens klausul uten endring.

Hvis vi trenger å endre $ mens klausul, gjør vi dette ved:

  • få begynnelsen av WHERE-klausulen: 'OG (('
  • få resten av WHERE-klausulen
  • injisere vår WHERE-klausul for å søke i Post Meta-tabellen meta_value kolonne for alle forekomster av søkeordet vårt
  • legger til en OR-betingelse til slutten av WHERE-klausulen, legger resten av spørringen til den
  • gruppering av resultatene med post-ID

Vi må gruppere resultatene fordi det vanligvis vil være mer enn en oppføring i Post Meta-tabellen for en gitt post-ID. Fordi vi satt opp et JOIN mellom innleggene og deres innleggsmetode, hvis vi ikke grupperte resultatene, ville vi få det samme innlegget som gjentas i vårt bord.

For å sjekke at våre JOIN og WHERE-klausuler har fungert, må du laste inn kontakttabellen din og forsøke å søke etter en av dine kontakter ved en del av deres telefonnummer:

Hvis det virker, gratulerer! Du kan nå søke etter eventuelle avanserte egendefinerte felt du angir i ditt CRM-system.

Neste…

I neste artikkel skal vi begrense og skjule WordPress Administration-funksjonalitet og menyelementer som vi ikke trenger for CRM.