WordPress Settings API, Del 5 Tabbed Navigation för inställningar

Vid denna tidpunkt i serien har vi tittat på Inställnings API och vad den har att erbjuda. Vi har till och med börjat skapa vårt eget tema för att hjälpa till att demonstrera allt vi har läst. Vi har täckt sektioner, fält, inställningar, menyer, sidor med mera.

Om du har följt med från början har du antagligen märkt att dessa artiklar är långa och är kodintensiva. Vi har träffat de viktigaste punkterna i inställnings API, så för de återstående artiklarna ska vi ta en kortare och mer fokuserad inställning på resten av ämnena. Detta kommer att minska längden på våra artiklar och hur mycket kod vi skriver och förhoppningsvis göra några av idéerna lite enklare att smälta.

Förra gången slutade vi mitt i utvecklingen: Vi har framgångsrikt skapat vår egen options sida och infört några nya alternativ, men vi lämnade projektet i ett tillstånd som hindrade alla våra alternativ att sparas på rätt sätt. I den här artikeln ska vi titta på varför vi inte kan spara våra alternativ och vad vi kan göra för att åtgärda det.

Innan vi börjar: I den här artikeln förutsätter du att du är bekant med inställnings API och temaalternativ. Om du är en nybörjare eller till och med mellan WordPress-utvecklare rekommenderar jag starkt att fånga upp resten av serien innan du dyker in i det här inlägget.

Varför kommer inte mina alternativ att spara?

Om du har följt igenom genom denna serie, bör din options sida se något ut så här:

Allt ser bra ut, men det finns ett problem med denna inställning - "Social Options" -värdena sparas ordentligt men "Display Options" kommer inte att. Innan vi går vidare är det viktigt att förstå varför vi kan göra våra alternativ ute på en enda sida, men vi kan inte spara båda alternativen.

Minns det tidigare i serien, definierade vi två uppsättningar inställningar för vårt tema - "Visningsalternativ" och "Sociala alternativ". Genom att använda Inställnings API berättar vi WordPress för att skapa poster för varje grupp av inställningar i databasen. Eftersom vi har definierat två grupper av inställningar skapas två rader i databasen. Därefter gör API-inställningarna alternativen till instrumentpanelen med hjälp av formulärelement. Därifrån tar WordPress formulärvärdena och sparar dem till databasen.

För att ge en högre säkerhetsnivå tilldelar WordPress varje grupp inställningar ett unikt värde som heter en nonce som skyddar mot skadliga attacker. Eftersom ett nonce-värde tillämpas för varje grupp av inställningar, utför vi för närvarande en enda blankett med två nonces. När du skickar formuläret till servern kommer WordPress bara att se (och därmed använda) det "senaste" nonce-värdet. I vårt fall är det "Sociala alternativ". Som sådan är endast dessa alternativ serialiserade - "Visningsalternativ" ignoreras helt.

Det här är inte väldigt avancerat - faktiskt kan du faktiskt se de två nonce-värdena för var och en av våra avsnitt när du tittar på källan till sidan. Här är nonce för "Display Options:"

Och här är nonce för de sociala alternativen:

Dina faktiska värden kommer att vara olika, men inmatningselementet kommer att finnas.

Ett sätt att förhindra att problemet uppstår är att skapa en unik sida för varje grupp av inställningar. Det här är inte en dålig lösning, men om du bara arbetar med en grupp med ett eller två alternativ kan det vara lite överkill att skapa en helt ny sida..

Lyckligtvis stöder WordPress mitt i mitten - du kan fortfarande behålla alla dina inställningar på en enda sida, men se till att användarna kan spara alla sina inställningar och fortfarande ha en trevlig användarupplevelse.

Ange Tabbed Navigation

Du har utan tvekan sett flikad navigering i WordPress-instrumentpanelen. Ta en titt på "Teman" -sidan:

Tabbed Navigation ger ett bra alternativ för att gruppera uppsättningar relaterade alternativ till en enda sida utan att göra den övergripande användarupplevelsen avkallad. Det här är vad vi ska implementera i Sandbox-teman.

Innan du skriver någon kod är det alltid en bra praxis att lista ut exakt vad vi ska göra under hela utvecklingen.

Introducera två flikar - en för visningsalternativ och en för sociala alternativ
Ställ in "Skärmalternativ" som standardflik när sidan laddas
Se till att samma flik är markerad som aktiv efter att ha sparat en viss sida med alternativ
Verifiera att uppdateringsmeddelandet görs när inställningarna sparas

Lägga till enskilda flikar

I functions.php, lokalisera sandbox_theme_display. Det här är den funktion som vi använder för att faktiskt göra alternativsidan. Från och med nu ska det se ut så här:

funktion sandbox_theme_display () ?>

Tandalternativ för sandlåda

Låt oss först introducera våra två flikar. Detta är relativt enkelt eftersom vi kommer att dra nytta av CSS-klasser som WordPress redan tillhandahåller - nämligen, nav-tab-wrapper och nav-fliken. I sandbox_theme_display funktion, släpp följande HTML-block precis under anropet till settings_errors ():

  Visa alternativ Sociala alternativ

Självklart är detta väldigt grundläggande, men vi har just introducerat två stylade flikar som vi ska använda hela resten av handledningen. Vid denna tidpunkt ska din kod se så här ut:

funktion sandbox_theme_display () ?>

Tandalternativ för sandlåda

Visa alternativ Sociala alternativ

Och din inställningssida ska se ut så här:

Bringa tabbarna till livet

För att börja byta våra alternativsidor, måste vi ge någon typ av signal eller flagg för vilka alternativ vi vill göra. Detta kan göras med hjälp av en variabel för söksträngar som identifierar vilken flik som klickades och som i sin tur kan läsas med hjälp av PHP.

Så låt oss gå framåt och ge varje ankare som vi skapade ovan en unik flagg som signalerar vilken flik vi försöker ladda. Uppdatera din markering så här:

  Visa alternativ Sociala alternativ

Var uppmärksam här så att du inte missar det här: Vi har angett två frågesträngvariabler i varje länk - sidvärdet och flikvärdet. Sidvärdet är nödvändigt eftersom det genereras av WordPress via Inställningar API och används för att berätta för vilken applikation vilken sida som ska laddas. Det andra värdet är ett godtyckligt värde som vi har använt för att signalera vilken flik vi är på. Om du tillåter att du har gjort det korrekt måste du observera att webbläsarens adressfält ska återspegla värdena som du klickar på varje flik.

Därefter måste vi skriva en liten bit av PHP som läser det nya söksträngsvärdet. I slutändan är den här koden vad som tillåter oss att byta till vår options sida, men vi ska ta det här ett steg i taget. Så, låt oss börja med att skriva en villkorlig för att kontrollera om frågesträngsvärdet är inställt och, om så, lagra det i en variabel. Detta kan gå direkt ovanför vårt nav-tab-wrapper som vi har definierat ovan.

WordPress ger en klass som heter nav-tab-aktiv att vi kan ansöka på våra ankareflikar för att stile dem som aktiva. Som sådant kommer vårt nästa steg att vara att jämföra värdet av $ active_tab variabel till variabeln för flervalsfrågor och använd sedan det klassnamnet på den aktuella fliken.

För att göra detta, uppdatera din kod så att den ser ut så här:

  "> Visa alternativ"> Sociala alternativ

Här märker vi att vi har skrivit inline PHP i klassattributet för varje ankare. I huvudsak säger koden "Om den aktiva flikvariabelns värde är" display_options ", echo det nav-flikaktiva sökordet, annars ska du inte echo något". Lätt nog, eller hur? Testa det ett par gånger - du borde se att alla dina flikar växlar fram och tillbaka.

Vid denna tidpunkt ska din funktion se så här ut:

funktion sandbox_theme_display () ?>

Tandalternativ för sandlåda

"> Visa alternativ"> Sociala alternativ

Men vänta - det finns en subtil bugg i den här koden! Minns att när en användare landar på inställningssidan första gången finns det inget värde för flik i frågesträngen. Som sådan måste vi ange en som standard. För att göra detta, låt oss uppdatera den villkorliga som kontrollerar förekomsten av frågesträngsvariabeln. Medan vi är på det, låt oss konsolidera den med hjälp av den ternära operatören:

 $ active_tab = isset ($ _GET ['flik'])? $ _GET ['flik']: 'display_options';

Det här säger att "om sökfrågan innehåller ett värde för" flik ", tilldela den till den aktiva fliken variabeln, annars ange värdet för" display_options. "" Det här är exakt hur vi ställer in fliken Visa som aktiv. Återigen, prova dina flikar.

Byta vår inställningssida

Vi är nästan färdiga! Det sista vi behöver göra är att byta vår inställningssida baserat på vilken flik som är aktiv. Specifikt vill vi bara visa visningsalternativen när skärmfliken är vald (och samma för våra sociala alternativ).

Eftersom vi har allt lagrat i active_tab variabel, borde vi kunna sätta ihop våra inställningar API-samtal i en villkorlig och vara bra att gå. Hitta först följande kodkod i ditt tema:

Observera att vi har två samtal till settings_fields och do_settings_section. I grund och botten vill vi bara göra en enda grupp när en viss flik väljs. För att göra detta skriver vi bara en villkorlig som kontrollerar värdet av $ active_tab och kör sedan lämplig sektion:

Uppdatera din options sida - tillåter att du har gjort allt korrekt, varje grupp av inställningar ska växla baserat på fältet och alla dina alternativ ska sparas på rätt sätt.

Slutsats

Tabbed Navigation är ett enkelt sätt att gruppera relaterade alternativ tillsammans och ge dina användare en gedigen användarupplevelse genom att inte översvämma dem med alternativ. Det är relativt enkelt att implementera och går långt för att strikt integrera dina alternativ med det inbyggda WordPress-utseendet.

I nästa inlägg bygger vi vidare på det här genom att exponera en översta menyn som gör dina tematillgängliga tillgängliga via menyn längs sidan av WordPress instrumentpanel.

Koda