Share
De volgende grote release van WordPress is al om de hoek. Dit is een grote voor thema-auteurs met een grote nadruk op postformaten. Er is een nieuwe gebruikersinterface voor postformaten voor de eindgebruiker van WordPress, samen met een nieuw systeem voor het verwerken en weergeven van deze gegevens in onze thema's. In dit artikel zal ik ingaan op wat u als thema-auteur voor postformaten in de komende WordPress 3.6 moet weten.
Bepaalde aspecten van toepassingen of technieken die in deze zelfstudie worden gebruikt, zijn gewijzigd sinds de publicatie oorspronkelijk werd gepubliceerd. Dit maakt het misschien een beetje moeilijk om mee te volgen. We raden u aan deze meer recente zelfstudies over hetzelfde onderwerp te bekijken:
In termen van recente grote WordPress-releases heeft 3.3 een aantal belangrijke verbeteringen aangebracht in de algehele beheerinterface, 3.4 heeft de thema-aanpasser geïntroduceerd en 3.5 heeft een nieuwe manier opgenomen waarop gebruikers media kunnen beheren. Als je een auteur bent met thema's die er momenteel zijn, ben je waarschijnlijk behoorlijk op je gemak geweest met deze laatste paar grote releases en hoefde je niet veel te doen op het gebied van updates of klantenondersteuning. Dit is echter mogelijk niet het geval met WordPress 3.6.
De grote focus van 3.6 ligt op postformaten. Post-formaten zijn terug in 3.1 geïntroduceerd, maar tot nu toe zijn ze altijd met nogal wat onbestendigheid gekomen. Iedereen heeft een andere kijk op postformaten en ze lijken min of meer populair in verschillende kringen van de WordPress-community en met verschillende soorten thema's.
Of je nu een fan bent of niet, WordPress heeft een gedurfde, nieuwe houding aangenomen ten aanzien van postformaten. Dus het is tijd om erover na te denken in uw themaontwerpen, ongeacht welke soorten WordPress-thema's u aan het maken bent, of dat u ze al verwerkt of niet. Hoewel je dit altijd moet doen, is dit minimaal een van die grote WordPress-releases die je echt met je thema's wilt testen voordat deze officieel wordt vrijgegeven.
Als auteur van een WordPress-thema, wil je de nieuwe gebruikersinterface voor berichtindelingen begrijpen die mogelijk aan de eindgebruiker wordt gepresenteerd, hoe dit overeenkomt met het nieuwe concept van gestructureerde postformaten en alle nieuwe functionaliteit van thema 3.6 introduceert voor postformaten.
Hopelijk moedigt dit artikel je aan om een vroege blik te werpen op bètaversie van WordPress 3.6, te beginnen met het werken met postformaten en dingen op weg te helpen met je thema's voordat het de massa bereikt.
Het eerste dat WordPress-eindgebruikers zullen opvallen tijdens het updaten naar WordPress 3.6, en wat u gaat doen als thema-auteur, is de geheel nieuwe gebruikersinterface voor postformaten..
In dit bericht is UI-ontwerp opgemaakt. In de bètastadium zijn al enkele wijzigingen doorgevoerd, maar hier is het WordPress-team momenteel aanwezig wanneer de eindgebruiker een nieuw bericht toevoegt, dankzij een kleine ontwerpinspiratie van Sara Cannon in WordPress-bericht opnieuw denken Format UI.
Bovendien heeft WordPress ook een subtiele, grafische verbetering opgenomen bij het beheren van alle berichten door een pictogram toe te voegen dat de huidige indeling naast elke berichttitel vertegenwoordigt.
Het nieuwe concept van gestructureerde postformaten is in wezen dat WordPress nu gestandaardiseerde gestructureerde gegevens aanmaakt die kunnen worden gebruikt bij het weergeven van bepaalde items die zijn gekoppeld aan berichten van verschillende formaten.
De nieuwe gebruikersinterface voor postformaten is meer dan alleen een mooiere manier om het formaat van elk bericht te selecteren. Bij sommige indelingen worden gebruikers nu velden aangeboden om deze gestructureerde gegevens te verzamelen die bij de berichten horen. Wanneer u bijvoorbeeld het "Video" -formaat selecteert, krijgt de gebruiker een veld om een video in te voeren.
Tot nu toe moesten auteurs van thema's die postformaten wilden integreren moeilijke beslissingen nemen over hoe gebruikers gegevens voor deze formaten gaan invoeren. Dit heeft zeker nogal wat onzekerheid veroorzaakt voor gebruikers die met verschillende thema's werken.
De postindelingen die nu gestructureerde gegevens bevatten, omvatten het volgende:
Accentsconagua
Hoewel we nog steeds in bèta zitten en al het bovenstaande is op dit moment nog niet in de haak, is er hier veel gedaan om de standaardisatie te verbeteren.
Als alles klaar is, is er altijd ruimte voor debat, ongeacht de uitkomst. De indeling 'Link' heeft bijvoorbeeld een veld voor de link-URL, maar moet deze ook een veld bevatten voor de tekst die aan die link is gekoppeld? De standaardfunctie hier is dat de titel van het bericht dient als de tekst voor de link. Is dit goed of fout? Iedereen zal daar een andere mening over hebben en je kunt zeker debatten beginnen met alle gestructureerde postformattegegevens.
Met standaardisatie komen dit soort gewaagde beslissingen en we moeten accepteren dat voor het welzijn van de WordPress-gemeenschap om verder te gaan. We moeten werken met de nieuwe normen en ons best doen om gebruikers een meer uniforme beheerderservaring te bieden.
Voor degenen die niet specifiek ondersteuning voor gestructureerde postformaten in hun thema's toevoegen, heeft WordPress 3.6 de nieuwe opgenomen post_formats_compat () functie. Deze nieuwe functie wordt automatisch gefilterd de inhoud(). Dit werkt hand in hand met het nieuwe gestructureerde concept voor postindelingen om standaard fallback-gedrag voor deze gestructureerde gegevens uit te voeren.
Bijvoorbeeld in een thema dat niet specifiek toevoegt "gestructureerde-post-formats"ondersteuning voor" Afbeelding "berichten, wanneer het thema wordt uitgevoerd de inhoud() met een bericht van dit formaat filtert WordPress automatisch in een weergave van de afbeelding die de gebruiker heeft geselecteerd.
Wat hier interessant aan is, en wat de reden is voor enkele verwarrende discussies, is wat het betekent om themaondersteuning toe te voegen voor: "gestructureerde-post-formats"voor een bepaald formaat. Wanneer u dit doet, zegt u niet dat uw thema de gegevens ondersteunt die door de gebruiker worden ingevoerd, maar in plaats daarvan zegt u effectief dat u niet wilt dat de gegevens automatisch worden gefilterd op de inhoud() voor het gegeven berichtformaat.
Met andere woorden, wanneer u toevoegt "gestructureerde-post-formats"ondersteuning voor een specifiek postformaat met add_theme_support (), je schakelt uit post_formats_compat () wanneer je thema wordt weergegeven de inhoud(). Dit is het geval voor de formaten - afbeelding, link, video, audio en aanhalingstekens - die de gebruiker vragen om gestructureerde gegevens.
Dit idee is een beetje verwarrend omdat tot nu toe, gebruiken add_theme_support () betekende altijd het toevoegen van ondersteuning voor een functie die WordPress standaard niet ondersteunt, zoals postminiatuur, aangepaste achtergronden, enzovoort. De gestructureerde gegevens van postformaten zijn nu echter een standaardfunctie van WordPress. Dus, het gebruik van add_theme_support () In dit geval gaat het meer over hoe u omgaat met het verwerken van die gestructureerde gegevens in uw themabestanden.
Maak je geen zorgen als dit nog niet helemaal klikt. We zullen dit verder bespreken met specifieke codevoorbeelden in de volgende sectie, en het zal logischer zijn met enkele van de nieuwe themafunctionaliteit die je kunt gebruiken.
Met de nieuwe gebruikersinterfaces UI en gestructureerde gegevens introduceert WordPress 3.6 nogal wat nieuwe functionaliteit die u kunt gebruiken in uw thema's.
Of de definitieve versie van WordPress 3.6 al dan niet standaard gebruikersinterfaces voor berichten heeft, u wilt toch registreren dat uw thema postformaten uit uw themafunctiesbestand ondersteunt, zoals u eerder deed, voor continuïteit. Het verschil is echter nu dat u ook wilt aangeven welke indelingen "gestructureerde-post-formats"ondersteuning.
add_theme_support ('structured-post-formats', array ('link', 'video')); add_theme_support ('post-formats', array ('terzijde', 'audio', 'chat', 'galerij', 'afbeelding', 'quote', 'status')); Let op in het bovenstaande voorbeeld, omdat "link"en"video-"formaten hebben"gestructureerde-post-formats"ondersteuning, ze hoefden niet te worden toegevoegd aan de algemene"post-formats"ondersteuning, omdat dit automatisch gebeurt.
De formaten die het zinvol is om toe te voegen "gestructureerde-post-formats"Ondersteuning voor kan mogelijk degenen omvatten die gegevens van de gebruiker verzamelen - afbeelding, link, video, audio of citaat.
Welk tastbaar effect heeft het toevoegen van thema-ondersteuning voor gestructureerde postformaten? -- Eigenlijk betekent dit dat alle oproepen naar de inhoud() want de ondersteunde formaten zullen geen 3.6's nieuw hebben post_formats_compat () toegepast die we in de vorige paragraaf hebben besproken.
In elk WordPress-thema dat je ooit hebt gemaakt, heb je het gebruikt de inhoud() om de inhoud van het bericht weer te geven, toch? Welnu, WordPress 3.6 heeft een nieuwe functie genaamd the_remaining_content () dat kan in plaats daarvan worden gebruikt, als je wilt.
Dit levert in wezen gewoon de inhoud van de post zonder de gestructureerde post-formaat gegevens erin.
Laten we bijvoorbeeld stellen dat u instelt hoe een post met het "Beeld" -formaat in uw thema wordt weergegeven. Gebruik makend van the_remaining_content () zal de inhoud van de post uitvoeren, zodat u de bijbehorende afbeelding uit de gestructureerde postformaatgegevens in de opmaak van uw thema ergens anders kunt weergeven. Merk op dat u in dit geval dat zou doen niet moet toevoegen "gestructureerde-post-formats"ondersteuning voor het" Beeld "-formaat omdat u het niet gebruikt de inhoud().
In termen van het weergeven van de gestructureerde gegevens, heeft WordPress 3.6 een aantal zeer gebruiksvriendelijke functies gegeven die alles omvatten. In uw themabestanden kunt u hiermee de gestructureerde gegevens afzonderlijk van de inhoud weergeven, als dat is wat u in uw themaontwerp wilt doen.
Een praktisch voorbeeld van het gebruik van een van deze kan er ongeveer zo uitzien voor het post-formaat "Afbeelding":
En nogmaals om te herhalen, met dit voorbeeld van het weergeven en gebruiken van een "Image" -post the_remaining_content (), je zou niet moet toevoegen "gestructureerde-post-formats"thema-ondersteuning omdat u niet gebruikt de inhoud().
Als u echter het volgende zou doen de inhoud(), je zou moeten toevoegen "gestructureerde-post-formats"ondersteuning voor de" afbeelding "-indeling, anders zou u de afbeelding twee keer zien verschijnen.
de inhoud() Als u de functies die we tot nu toe hebben besproken niet gebruikt en u vertrouwt gewoon op het gebruik ervan de inhoud() om alle gestructureerde post-formaat gegevens weer te geven, is er een ding dat je zult opmerken dat je misschien wel, of misschien niet, vreemd zult vinden. Met uitzondering van het "Link" -formaat, heeft WordPress setup post_formats_compat () om alle gestructureerde gegevens weer te geven na de inhoud van de post.
Als dit niet bevalt, is er een filter dat u kunt gebruiken om het te wijzigen. Hier is hoe je het zou doen vanuit het functiedossier van je thema:
function my_post_format_compat_args ($ args) $ args ['position'] = 'before'; $ args teruggeven; add_filter ('post_format_compat', 'my_post_format_compat_args'); Als u iets op maat wilt doen met deze gestructureerde gegevens, worden ze gewoon opgeslagen als meta voor de berichten die u gemakkelijk kunt ophalen get_post_meta (), zoals gewoonlijk.
En om een enkele array van alle post-formaat metadata voor een bepaald bericht op te halen, kunt u het nieuwe gebruiken get_post_format_meta () functie om alles in één keer te pakken.
Ik weet dat toen de postformaten voor het eerst uitkwamen, het "Chat" -formaat er altijd één was waarvan ik niet echt wist hoe ik het moest aanpakken. Hoe heeft de gebruiker de chat ingevoerd in de inhoud van het bericht? Hoe laten we het zien? Met het nieuwe the_post_format_chat () functie, er is nu meer een duidelijke standaard.
De verwachting is dat de gebruiker een chat gaat plaatsen in de inhoud van de post-opmaak, iets als dit:
John: foo Mary: bar John: foo 2
De gebruiker kan ook datums en tijden opnemen. Merk op dat dit zou zijn hoe het eruit ziet als de gebruiker rechtstreeks kopieert en plakt van een Skype-gesprek, wat het idee is achter de coole, nieuwe chat-parsers.
[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
En dan in uw thema, waar u het "Chat" -formaat weergeeft, kunt u eenvoudigweg vervangen de inhoud() met the_post_format_chat () iets zoals dit:
Hierdoor wordt het chatitem van de gebruiker automatisch geconverteerd naar een aantal gestandaardiseerde, semantische markeringen die we allemaal kunnen stylen over onze thema's. De enige echte vangst hiervan is dat wordt aangenomen dat de inhoud alleen de chat bevat en niets anders vóór of na. Ik geloof echter dat dit vrij algemeen was voor de meeste thema-auteurs in hoe ze de "Chat" -postformats eerder al behandelden.
Als u de onbewerkte geparseerde gegevens uit het chat-transcript van een bericht wilt halen, kunt u deze functie ook gebruiken get_the_post_format_chat (). Hiermee wordt een array met chat-transcriptiegegevens geretourneerd die u vervolgens kunt manipuleren met uw eigen HTML-markup.
function my_chat_display () $ stanzas = get_the_post_format_chat (); foreach ($ strofen als $ stanza) foreach ($ stanza als $ rij) // ... // ...
En tot slot, wat als u de nieuwe gebruikersinterface voor postformaten wilt verbergen? Natuurlijk, WordPress geeft je hier een filter voor.
add_filter ('enable_post_format_ui', '__return_false'); Notitie: Dit filter is toegevoegd met 3.6-beta2 (Trac-ticket # 23929). Maar ik denk dat de vraag meer is moeten jij doet dit? Ik zou geneigd zijn te zeggen dat dit waarschijnlijk niet het beste zou zijn om te doen in de meeste gevallen. Aangezien de gebruikersinterface voor postformaten mogelijk een standaardonderdeel van WordPress wordt, zou je deze in wezen gewoon van de eindgebruiker verwijderen.
Als u een geheel ander aangepast systeem hebt gemaakt voor het verzamelen van gegevens om met postformaten te gebruiken en u verbergt de standaard UI, kan dit de eindgebruiker op de lange termijn een beetje verwarren met standaardisatie. Is dat slecht of goed? Ik weet het niet; het is gewoon iets om over na te denken. - Ironisch genoeg denk ik dat degenen die postformaten eerder in hun thema's hebben opgenomen, het meeste werk hebben te maken met updates voor de 3.6-release, in tegenstelling tot degenen die er nog geen last van hebben gehad.
Als blijkt dat de WordPress 3.6 officieel de UI voor postformaten standaard zichtbaar heeft en u de UI verbergt omdat u het niet in uw thema aanpakt, dan zou ik kunnen zien hoe sommigen dit mogelijk als een beetje lui zouden kunnen zien.
Met een moedig besluit om dit allemaal in WordPress op te nemen, is het duidelijk dat er een grote nadruk ligt op postformaten die vooruitgaan. Het is waarschijnlijk het beste dat u ervoor zorgt dat uw thema's ten minste elementaire ondersteuning bieden, als er niets anders is, om bij te dragen aan een meer gestandaardiseerde WordPress-ervaring.
Realistisch gezien is dit waarschijnlijk een fluitje van een cent met de nieuwe compatibiliteitsfunctie voor postformaten. Er is een grote kans dat uw niet-post-formatthema al behoorlijk veel werkt met de nieuwe gestructureerde gegevens. U wilt er in ieder geval gewoon zeker van zijn dat zaken als chattranscripten en het citaatformaat mooi weergeven in termen van de CSS van uw thema.
En voor diegenen die creatief willen worden met het weergeven van berichten van verschillende formaten binnen je thema's, heb je nu een heleboel geweldige nieuwe themafuncties om mee te spelen.
