Share
Nästa stora version av WordPress finns redan runt hörnet. Detta är en stor för temaförfattare med ett stort fokus på postformat. Det finns ett nytt postformat-gränssnitt för WordPress-slutanvändaren, tillsammans med ett nytt system för hantering och visning av denna data i våra teman. I den här artikeln kommer jag att täcka vad du behöver veta som temaförfattare för postformat i den kommande WordPress 3.6.
Vissa aspekter av tillämpningar eller tekniker som används i denna handledning har ändrats sedan den ursprungligen publicerades. Detta kan göra det lite svårt att följa med. Vi rekommenderar att du tittar på de senaste tutorialsna om samma ämne:
När det gäller de senaste stora WordPress-utgåvorna har 3.3 gjort några signifikanta förbättringar av det övergripande admingränssnittet, 3.4 introducerade temat anpassningsanordningen och 3.5 infördes ett nytt sätt för användarna att hantera media. Om du är en författare med teman som finns där ute, har du förmodligen varit ganska bekväm med de senaste några stora utgåvorna och har inte behövt göra mycket när det gäller uppdateringar eller kundsupport. Detta kan dock inte vara fallet med WordPress 3.6.
Det stora fokuset på 3,6 är på postformat. Postformat introducerades tillbaka i 3.1, men hittills har det alltid kommit med en hel del inkontinuitet. Alla har ett annat tag på postformat och de verkar vara mer eller mindre populära i olika cirklar i WordPress-samhället och med olika typer av teman.
Oavsett om du är ett fan eller inte, har WordPress tagit en djärv ny inställning på postformat. Så det är dags att börja tänka på dem i dina tematyper, oavsett vilka typer av WordPress-teman du skapar, eller om du redan införlivar dem eller inte. Även om du alltid ska göra detta, är det här ett av de stora WordPress-utgåvorna som du verkligen vill testa med dina teman innan det släpps officiellt.
Som en WordPress-temforfattare vill du förstå det nya postformat-användargränssnittet som eventuellt kommer att presenteras för slutanvändaren, hur det här motsvarar det nya konceptet med strukturerad postformat och allt nytt temafunktionalitet 3.6 introducerar för postformat.
Förhoppningsvis kommer den här artikeln att uppmuntra dig att ta en snabb titt på WordPress 3.6 beta, börja arbeta med postformat och få saker att rulla med dina teman innan det träffar massorna.
Det första som WordPress slutanvändare kommer att märka när man uppdaterar till WordPress 3.6, och vad som ska ge dig effekt som temaförfattare, är det helt nya postformat-gränssnittet.
Det här inlägget UI-design har redan gått igenom några förändringar i beta-scenen, men här är där WordPress-teamet är för närvarande när slutanvändaren lägger till ett nytt inlägg tack vare en liten designinspiration från Sara Cannon i Re-thinking WordPress Post Format UI.
Dessutom har WordPress också införlivat en subtil grafisk förbättring när man hanterar alla inlägg genom att lägga till en ikon som representerar det aktuella formatet bredvid varje posttitel.
Det nya konceptet med strukturerad postformat är i huvudsak att WordPress nu etablerar standardiserade strukturerade data som kan användas vid visning av vissa objekt i samband med inlägg av olika format.
Det nya postformat-användargränssnittet är mer än bara ett trevligare sätt att välja formatet för varje inlägg. Med några av formaten presenteras användarna nu med fält för att samla in denna strukturerade data för att vara associerad med inläggen. När du till exempel väljer "Video" -format, presenteras användaren sedan med ett fält för att mata in en video.
Hittills har temaförfattare som väljer att ta med postformat tvingats ta tuffa beslut om hur användarna ska mata in data för dessa format. Det har säkert lagt till en del inconstancy för användare som arbetar med olika teman.
Postformaten som nu har strukturerad data som är associerade med dem inkluderar följande:
Accentsconagua
Medan vi fortfarande är i beta, och allt ovanstående är inte stilla för tillfället så har mycket här gjorts i slutändan för standardiseringens skull.
När det är klart, oavsett vad resultatet kommer, kommer det alltid finnas utrymme för debatt. Länken "Link" -formatet har till exempel ett fält för länken URL, men ska det också ha ett fält för texten som är associerad med den länken? Standardfunktionen här är att titeln på posten fungerar som texten för länken. Är det rätt eller fel? Alla kommer att ha en annan åsikt om dessa saker och du kan säkert börja debattera med alla strukturerad postformatdata.
Med standardisering kommer dessa slags djärva beslut och vi måste acceptera det för att WordPress-communityet ska kunna gå vidare. Vi måste arbeta med de nya standarderna och göra vårt bästa för att ge användarna en mer enhetlig adminupplevelse.
För dem som inte specifikt lägger till stöd för strukturerad postformat i sina teman har WordPress 3.6 införlivat det nya post_formats_compat () fungera. Den här nya funktionen filtreras automatiskt på innehållet(). Detta fungerar hand i hand med det nya strukturerade postformatkonceptet för att utföra standardbackback-beteendet för denna strukturerad data.
Till exempel, i ett tema som inte specifikt lägger till "strukturerad-post-format"stöd för" Bild "inlägg, när temat utmatas innehållet() med ett inlägg i detta format filtrerar WordPress automatiskt i en bildvisning av den bild som användaren valt.
Vad som är intressant om detta, och vad som orsakar några förvirrande diskussioner, handlar om vad det innebär att faktiskt lägga till temat stöd för "strukturerad-post-format"för ett visst format. När du gör det säger du inte att ditt tema stöder de data som användaren inmatat, men i stället säger du att du inte vill att data automatiskt filtreras på innehållet() för det angivna postformatet.
Med andra ord, när du lägger till "strukturerad-post-format"stöd för ett visst postformat med add_theme_support (), du stänger av post_formats_compat () när ditt tema utmatas innehållet(). Det här är fallet för formatet - bild, länk, video, ljud och citat - som alla uppmanar användaren till strukturerad data.
Denna idé är lite förvirrande för att till och med använda add_theme_support () alltid menat att lägga till stöd för någon typ av funktion som WordPress inte stödjer som standard, som efter miniatyrbilder, anpassade bakgrunder etc. De strukturerade data för postformat är nu en standardfunktion för WordPress. Så, användningen av add_theme_support () i det här fallet handlar det mer om hur du närmar dig hanteringen av den strukturerade data i dina temafiler.
Oroa dig inte om detta inte klickar helt riktigt än. Vi kommer att diskutera detta ytterligare med specifika kodexempel i nästa avsnitt, och det blir mer meningsfullt med en del av den nya temafunktionaliteten du kan använda.
Med det nya postformat-användargränssnittet och strukturerad data introducerar WordPress 3.6 ganska lite av en ny funktionalitet som du kan börja använda i dina teman.
Huruvida den slutliga versionen av WordPress 3.6 har standardformat-användargränssnitt som standard, vill du ändå registrera att ditt tema stöder postformat från din temafunktionsfil, som du gjorde tidigare, för kontinuitet. Men skillnaden är nu att du också vill ange vilka format som har "strukturerad-post-format" Stöd.
add_theme_support ('structured-post-formats', array ('länk', 'video')); add_theme_support ("postformat", array ("åt sidan", "ljud", "chatt", "galleri", "bild", "citat", "status")); Observera i ovanstående exempel, eftersom "länk"och"video-"format har"strukturerad-post-format"stöd, de behövde inte läggas till den allmänna"post-format"stöd, eftersom det händer automatiskt.
De format som det är vettigt att lägga till "strukturerad-post-format"stöd till kan eventuellt inkludera dem som samlar in data från användaren - bild, länk, video, ljud eller citat.
Vilken konkret effekt har faktiskt stöd för strukturerade postformat? -- I grund och botten betyder det att alla samtal till innehållet() för de stödda formaten kommer inte att ha 3,6 nya post_formats_compat () tillämpas som vi diskuterade i föregående avsnitt.
I varje WordPress-tema som du någonsin har skapat har du använt innehållet() för att visa innehållet i inlägget, eller hur? Jo, WordPress 3.6 har en ny funktion som heter the_remaining_content () som kan användas istället, om du vill ha det.
Detta ger väsentligen bara innehållet i inlägget utan strukturerad postformatdata i den.
Så till exempel, låt oss säga att du ställer in hur ett "Bild" formatpost visas i ditt tema. Använder sig av the_remaining_content () kommer att utmata innehållet i inlägget, så att du kan visa den associerade bilden från strukturerad postformatdata i ditt temas markup någon annanstans. Observera att i det här fallet skulle du inte måste lägga till "strukturerad-post-format"stöd för formatet" Bild "eftersom du inte använder innehållet().
När det gäller att visa strukturerad data har WordPress 3.6 givit några mycket lättanvända funktioner som omfattar allt. I dina temafiler tillåter du att du visar de strukturerade data separat från innehållet, om det är vad du vill göra i din tematyp.
Ett praktiskt exempel på att använda en av dessa kan se ut så här för "Bild" postformat:
Och igen för att upprepa, med det här exemplet att visa en "Bild" -post och använda the_remaining_content (), du skulle inte måste lägga till "strukturerad-post-format"tema stöd eftersom du inte använder innehållet().
Men om du skulle göra följande med innehållet(), du skulle behöva lägga till "strukturerad-post-format"stöd för" Bild "-format, annars skulle du sluta med att bilden visas två gånger.
innehållet() Om du inte använder de funktioner vi har diskuterat hittills, och du är helt enkelt beroende av att använda innehållet() För att visa alla strukturerad postformatdata, det finns en sak du kommer att märka att du kanske, eller kanske inte, finner konstig. Med undantag för "Link" -formatet har WordPress setup post_formats_compat () för att visa all strukturerad data efter Innehållet i posten.
Om du inte gillar det här, finns det ett filter som du kan använda för att ändra det. Så här gör du det från ditt temas funktionsfil:
funktion my_post_format_compat_args ($ args) $ args ['position'] = 'före'; returnera $ args; add_filter ('post_format_compat', 'my_post_format_compat_args'); Om du vill göra något anpassat med denna strukturerade data sparas de bara som meta till de inlägg som du enkelt kan hämta med get_post_meta (), som alltid.
Och för att hämta en enda uppsättning av alla metatata för postformat för ett visst inlägg kan du använda det nya get_post_format_meta () funktion för att fånga allt i ett skott.
Jag vet att när inlägget först kom ut, var "Chat" -formatet alltid en jag visste inte riktigt hur jag skulle hantera. Hur lägger användaren in chatten i innehållet i inlägget? Hur visar vi det? Med den nya the_post_format_chat () funktion, det finns nu mer en klar standard.
Det förväntas att användaren ska prata i innehållet i inlägget formaterat något så här:
John: Foo Mary: Bar John: Foo 2
Användaren kan också innehålla datum och tider. Observera att det här skulle vara hur det ser ut om användaren kopierar och klistras direkt från en Skype-konversation, vilket är tanken bakom de coola nya chattparsarna.
[4/10/13 4:20:30 PM] John: foo [4/10/13 4:20:58 PM] Mary: bar [4/10/13 4:22:22 PM] John: foo 2
Och sedan i ditt tema, där du visar "Chatt" postformat, kan du helt enkelt byta ut innehållet() med the_post_format_chat () något som det här:
Detta konverterar automatiskt användarens chattinmatning till en standardiserad semantisk markering. Vi kan alla börja stila över våra teman. Den enda riktiga fångst med detta är att det antas att innehållet bara innehåller chatten och inget annat före eller efter. Men jag tror att det var ganska vanligt för de flesta temaförfattare hur de hanterade "Chat" -formatet tidigare, ändå.
Om du också vill hämta den rada analyserade data från ett inläggs chattranscript kan du använda funktionen get_the_post_format_chat (). Detta kommer att returnera en uppsättning av chatt-transkriptdata som du då kan manipulera med din egen HTML-uppställning.
funktion my_chat_display () $ stanzas = get_the_post_format_chat (); foreach ($ stanzas as $ stanza) foreach ($ stanza som $ rad) // ... // ...
Och äntligen, vad händer om du bara vill dölja det nya postformat-användargränssnittet? Jo, givetvis, WordPress ger dig ett filter för detta.
add_filter ('enable_post_format_ui', '__return_false'); Notera: Detta filter läggs till med 3,6-beta2 (Trac biljett nr 23929). Men jag antar att frågan är mer skall gör du det här? Jag brukar säga att det här förmodligen inte skulle vara det bästa att göra i de flesta fall. Eftersom postformat-användargränssnittet nu kan bli en standarddel av WordPress, skulle du i princip bara avlägsna den från slutanvändaren.
Om du har skapat ett helt annat anpassat system för att samla in data som ska användas med inläggsformat och du gömmer standardinställningarna, kan det hända att slutanvändaren lite förvirrar lite med standardisering på lång sikt. Är det dåligt eller bra? Jag vet inte; det är bara något att tänka på. - Ironiskt nog tror jag att de som har införlivat postformat tidigare i sina teman kommer att ha mest arbete med uppdateringar för 3.6-versionen, i motsats till de som inte har stört dem än.
Om det visar sig att WordPress 3.6 officiellt har postformat-användargränssnittet som standard och du döljer användargränssnittet bara för att du inte tar itu med det i ditt tema så kunde jag se hur eventuellt vissa kan uppleva detta som lite lat.
Med ett djärvt beslut att integrera allt detta i WordPress är det tydligt att det finns stor vikt vid postformat framåt. Det är nog bäst att du ser till att dina teman ger åtminstone grundläggande stöd, om inget annat, för att bidra till en mer standardiserad WordPress-upplevelse.
Realistiskt är det förmodligen en bit tårta med den nya funktionen för kompatibilitet i postformat. Det finns en bra chans att ditt icke-postformat tema redan fungerar ganska bra med de nya strukturerade data. Som ett minimum kan du bara se till att saker som chattranscriptioner och citatformatet visas snyggt när det gäller ditt temas CSS.
Och för dem som vill bli kreativa med att visa inlägg av olika format inom dina teman, har du nu massor av fantastiska nya temafunktioner att spela med.
