Share
Den neste store utgaven av WordPress er allerede rundt hjørnet. Dette er en stor for temaforfattere med stort fokus på postformater. Det er et nytt innleggformat-brukergrensesnitt for WordPress-sluttbrukeren, sammen med et nytt system for håndtering og visning av disse dataene i våre temaer. I denne artikkelen skal jeg dekke hva du trenger å vite som temaforfatter for innleggformater i kommende WordPress 3.6.
Visse aspekter av applikasjoner eller teknikker som brukes i denne opplæringen, har endret seg siden den ble opprinnelig publisert. Dette kan gjøre det litt vanskelig å følge med. Vi anbefaler å se på disse nyere opplæringsprogrammene på samme emne:
I forhold til de seneste store WordPress-utgivelsene har 3.3 gjort noen betydelige forbedringer av det generelle administrasjonsgrensesnittet, 3.4 introduserte tematilpasseren, og 3.5 innlemmet en ny måte for brukerne å administrere media. Hvis du er en forfatter med temaer for tiden der ute, har du sikkert vært ganske komfortabel med disse siste få utgivelsene, og du har ikke hatt mye å gjøre med oppdateringer eller kundesupport. Dette kan imidlertid ikke være tilfelle med WordPress 3.6.
Det store fokuset på 3,6 er på postformater. Postformater ble introdusert tilbake i 3.1, men har til nå alltid kommet med ganske ustansighet. Alle har en annen ta på postformater, og de synes å være mer eller mindre populære i ulike sirkler i WordPress-fellesskapet, og med forskjellige typer temaer.
Enten du er en fan eller ikke, har WordPress tatt en dristig, ny holdning til innleggformater. Så det er på tide å begynne å tenke på dem i temadesignene dine, uansett hvilke typer WordPress-temaer du lager, eller om du allerede innlemmer dem eller ikke. Selv om du alltid bør gjøre dette, er dette et av de store WordPress-utgivelsene som du virkelig vil teste med temaene dine før det blir offisielt utgitt.
Som en WordPress-temaforfatter vil du forstå det nye innleggformat-brukergrensesnittet som potensielt blir presentert til sluttbrukeren, hvordan dette tilsvarer det nye konseptet med strukturerte innleggformater, og alt nytt temafunksjonalitet 3.6 introduserer for postformater.
Forhåpentligvis vil denne artikkelen oppfordre deg til å ta en tidlig titt på WordPress 3.6 beta, begynne å jobbe med innleggformater, og få ting å rulle med temaene dine før det treffer massene.
Det første som WordPress-sluttbrukere kommer til å legge merke til når du oppdaterer til WordPress 3.6, og hva som kommer til å påvirke deg som temaforfatter, er det helt nye innleggsformatet UI.
Denne postformaten UI-design har allerede gått gjennom noen endringer i beta-scenen, men her er hvor WordPress-teamet er for tiden når sluttbrukeren legger til et nytt innlegg, takket være en liten designinspirasjon fra Sara Cannon i Re-thinking WordPress Post Formater brukergrensesnittet.
I tillegg har WordPress også innarbeidet en subtil, grafisk forbedring når du administrerer alle innlegg ved å legge til et ikon som representerer det nåværende formatet ved siden av hver posttittel.
Det nye konseptet med strukturerte innleggformater er i hovedsak at WordPress nå etablerer standardiserte strukturerte data som kan brukes til å vise bestemte elementer knyttet til innlegg i forskjellige formater.
Det nye innleggsformat-brukergrensesnittet er mer enn bare en finere måte å velge formatet på hvert innlegg på. Med noen av formatene blir brukerne nå presentert med felt for å samle denne strukturerte data som skal knyttes til innleggene. For eksempel, når du velger "Video" -format, blir brukeren deretter presentert med et felt for å legge inn en video.
Fram til nå har temaforfattere som velger å inkorporere postformater, truffet sterke beslutninger om hvordan brukere skal legge inn data for disse formatene. Dette har sikkert lagt til en del inkonstancy for brukere som arbeider med ulike temaer.
Postformatene som nå har strukturerte data knyttet til dem, inkluderer følgende:
Accentsconagua
Mens vi fortsatt er i beta, og alt ovenfor ikke er satt i stein for øyeblikket, har mye her blitt gjort til slutt for standardiseringens skyld..
Når det er satt, uansett hva utfallet, vil det alltid være rom for debatt. For eksempel har "Link" -formatet et felt for linkadressen, men skal det også ha et felt for teksten som er knyttet til den linken? Standardfunksjonaliteten her er at tittelen på innlegget fungerer som tekst for lenken. Er dette riktig eller galt? Alle vil ha en annen mening om disse tingene, og du kan sikkert begynne debatter med alle de strukturerte postformatdataene.
Med standardisering kommer slike dype beslutninger, og vi må akseptere det til fordel for WordPress-fellesskapet for å gå videre. Vi må jobbe med de nye standardene og gjøre vårt beste for å gi brukerne en mer samlet administrasjonsopplevelse.
For de som ikke spesifikt legger til støtte for strukturerte innleggformater i deres temaer, har WordPress 3.6 innarbeidet det nye post_formats_compat () funksjon. Denne nye funksjonen filtreres automatisk på innholdet(). Dette fungerer hånd i hånd med det nye strukturerte innleggformatskonceptet for å utføre standard tilbakebetaling for denne strukturerte data.
For eksempel, i et tema som ikke spesifikt legger til "strukturert-post-formater"Støtte for" Image "innlegg, når temaet utgir innholdet() Med et innlegg i dette formatfiltrerer WordPress automatisk i en visning av bildet brukeren valgte.
Hva er interessant om dette, og hva er årsaken til noen forvirrende diskusjoner, er rundt hva det betyr å faktisk legge til tema støtte for "strukturert-post-formater"for et bestemt format. Når du gjør dette, sier du ikke at temaet ditt støtter dataene som er innført av brukeren, men i stedet sier du effektivt at du ikke vil at dataene automatisk skal filtreres på innholdet() for gitt postformat.
Med andre ord, når du legger til "strukturert-post-formater"støtte for et bestemt innlegg format med add_theme_support (), du slår av post_formats_compat () når temaet ditt utgis innholdet(). Dette er tilfelle for formatene - bilde, lenke, video, lyd og sitat - som alle spør brukeren om strukturerte data.
Denne ideen er litt forvirrende fordi til nå, ved hjelp av add_theme_support () alltid ment å legge til støtte for en slags funksjon som WordPress ikke støtter som standard, som etter miniatyrbilder, egendefinerte bakgrunner etc. De strukturerte dataene i postformater er nå en standardfunksjon for WordPress. Så, bruken av add_theme_support () I dette tilfellet handler det mer om hvordan du nærmer deg håndtering av strukturerte data i temafilene dine.
Ikke bekymre deg hvis dette ikke er helt klikkende ennå. Vi diskuterer dette videre med spesifikke kodeeksempler i neste avsnitt, og det vil gjøre mer fornuftig med noen av de nye temafunksjonene du kan bruke.
Med den nye postformat-brukergrensesnittet og strukturerte data introduserer WordPress 3.6 ganske mye av en ny funksjonalitet du kan begynne å bruke i temaene dine.
Hvorvidt den endelige utgivelsen av WordPress 3.6 har standardformat-brukergrensesnitt som standard, vil du fortsatt registrere deg for at temaet ditt støtter innleggsformater fra temafunksjonsfilen, som du gjorde før, for kontinuitet. Men forskjellen er nå at du også vil spesifisere hvilke formater som har "strukturert-post-formater" Brukerstøtte.
add_theme_support ('structured-post-formats', array ('link', 'video')); add_theme_support ('postformater', array ('til side', 'lyd', 'chat', 'galleri', 'bilde', 'sitat', 'status')); Legg merke til i eksempelet ovenfor, fordi "link"og"video"formater har"strukturert-post-formater"støtte, de trengte ikke å bli lagt til den generelle"post-formater"støtte, da dette skjer automatisk.
Formatene det gir mening å legge til "strukturert-post-formater"Støtte til kan potensielt inkludere de som samler data fra brukeren - bilde, lenke, video, lyd eller sitat.
Hvilken konkret effekt har det å legge til tema støtte for strukturerte innlegg formater faktisk har? -- I utgangspunktet betyr det at noen ringer til innholdet() for de støttede formatene vil ikke ha 3,6 nye post_formats_compat () anvendt som vi diskuterte i forrige avsnitt.
I hvert WordPress-tema du noensinne har laget, har du brukt innholdet() å vise innholdet i innlegget, ikke sant? Vel, WordPress 3.6 har en ny funksjon som heter the_remaining_content () som kan brukes i stedet, hvis du vil.
Dette utfører i hovedsak bare innholdet i innlegget uten de strukturerte postformatdataene i den.
Så for eksempel, la oss si at du setter opp hvordan et "Image" format innlegg vises i temaet ditt. Ved hjelp av the_remaining_content () Vil utdata innholdet i innlegget, slik at du kan vise det tilknyttede bildet fra de strukturerte postformatdataene i temaets markup et annet sted. Merk at i dette tilfellet ville du ikke trenger å legge til "strukturert-post-formater"Støtte for" Image "formatet fordi du ikke bruker innholdet().
Når det gjelder å vise strukturerte data, har WordPress 3.6 gitt svært enkle å bruke funksjoner som omfatter alt. Innenfor temafilene dine lar disse deg vise strukturerte data separat fra innholdet, hvis det er det du vil gjøre i temaet design.
Et praktisk eksempel ved å utnytte en av disse kan se noe ut som dette for "Image" postformatet:
Og igjen for å gjenta, med dette eksempelet på å vise et "Bilde" innlegg og bruk the_remaining_content (), ville du ikke trenger å legge til "strukturert-post-formater"tema støtte fordi du ikke bruker innholdet().
Men hvis du skulle gjøre følgende med innholdet(), du må legge til "strukturert-post-formater"Støtte for" Image "-formatet, ellers vil du ende opp med at bildet vises to ganger.
innholdet() Hvis du ikke bruker funksjonene vi har diskutert så langt, og du er bare stolt på å bruke innholdet() For å vise alle de strukturerte postformatdataene, er det en ting du skal legge merke til at du kanskje, eller kanskje ikke, finner merkelig. Med unntak av "Link" -formatet har WordPress oppsett post_formats_compat () for å vise alle strukturerte data etter Innholdet i innlegget.
Hvis du ikke liker dette, er det et filter du kan bruke til å endre det. Slik gjør du det fra temaets funksjonsfil:
fungere my_post_format_compat_args ($ args) $ args ['posisjon'] = 'før'; returner $ args; add_filter ('post_format_compat', 'my_post_format_compat_args'); Hvis du vil gjøre noe skreddersydd med denne strukturerte data, blir de bare lagret som meta til innleggene du lett kan hente med get_post_meta (), som alltid.
Og for å hente et enkelt utvalg av alle postformat-metadataene for et bestemt innlegg, kan du bruke det nye get_post_format_meta () Fungerer for å ta alt i ett skudd.
Jeg vet at når postformater først kom ut, var "Chat" -formatet alltid en jeg visste egentlig ikke hvordan jeg skulle håndtere. Hvordan bruker brukeren inn chaten i innholdet i innlegget? Hvordan viser vi det? Med den nye the_post_format_chat () funksjon, det er nå mer av en klar standard.
Det forventes at brukeren skal snakke inn i innholdet i innlegget formatert noe slikt:
John: foo Mary: bar John: foo 2
Brukeren kan også inkludere datoer og tidspunkter. Vær oppmerksom på at dette ville være hvordan det ser ut hvis brukeren kopierer og limes direkte fra en Skype-samtale, noe som er ideen bak de kule, nye chatparsers.
[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
Og så i temaet ditt, hvor du viser «Chat» -formatet, kan du enkelt erstatte innholdet() med the_post_format_chat () noe sånt som dette:
Dette konverterer automatisk brukerens chatoppføring til noen standardiserte, semantiske oppslag, vi kan alle begynne å style over våre temaer. Den eneste virkelige fangsten med dette er at det antas at innholdet bare inneholder chatten og ingenting annet før eller etter. Imidlertid tror jeg dette var ganske vanlig for de fleste temaforfattere i hvordan de håndterte "Chat" -formatet tidligere, uansett.
Også, hvis du vil hente de rade analyserte dataene fra et innleggs chatutskrift, kan du bruke funksjonen get_the_post_format_chat (). Dette vil returnere en rekke av chat-transkripsjonsdataene som du deretter kan manipulere med din egen HTML-oppslag.
funksjon my_chat_display () $ stanzas = get_the_post_format_chat (); foreach ($ stanzas as $ stanza) foreach ($ stanza som $ rad) // ... // ...
Og til slutt, hva hvis du bare vil gjemme det nye postformat-brukergrensesnittet? Vel, selvfølgelig, gir WordPress deg et filter for dette.
add_filter ('enable_post_format_ui', '__return_false'); Merk: Dette filteret er lagt til med 3,6-beta2 (Trac billett # 23929). Men jeg antar at spørsmålet er mer bør du gjør dette? Jeg vil gjerne si at dette nok ikke ville være det beste å gjøre i de fleste tilfeller. Siden postformat-brukergrensesnittet nå kan ende opp som en standard del av WordPress, ville du egentlig bare være å fjerne den fra sluttbrukeren.
Hvis du har opprettet et helt annet tilpasset system for å samle inn data som skal brukes med innleggformater, og du skjuler standardbrukergrensesnittet, kan dette forvirre sluttbrukeren litt med standardisering i det lange løp. Er det ille eller bra? Jeg vet ikke; det er bare noe å tenke på. - Ironisk nok tror jeg de som har innlemmet postformater tidligere i temaene deres, vil ha mest arbeid med oppdateringer for 3.6-utgivelsen, i motsetning til de som ikke har plaget seg med dem ennå.
Hvis det viser seg at WordPress 3.6 offisielt har postformat-brukergrensesnittet synlig som standard, og du gjemmer brukergrensesnittet bare fordi du ikke adresserer det i temaet ditt, så kunne jeg se hvordan noen kanskje oppfatter dette som litt lat.
Med en dristig beslutning om å inkorporere alt dette i WordPress, er det klart at det legges stor vekt på postformater fremover. Det er sannsynligvis best at du sørger for at temaene dine gir minst grunnleggende støtte, hvis ikke noe annet, for å bidra til en mer standardisert WordPress-opplevelse.
Realistisk er dette sannsynligvis et stykke kake med den nye postformatkompatibilitetsfunksjonen. Det er en god sjanse at ditt ikke-postformat tema allerede fungerer ganske mye med de nye strukturerte dataene. På et minimum kan du bare sørge for at ting som chat-transkripsjoner og sitatformatene vises pent i forhold til temaets CSS.
Og for de som ønsker å bli kreative med å vise innlegg av ulike formater innenfor temaene dine, har du nå massevis av flotte nye temafunksjoner å spille med.
