Share
Aangepaste berichttype paginering heeft u naar beneden gehaald? Er is niets frustrerender aan het ontwikkelen voor WordPress dan ervoor te zorgen dat paginering op maat van het posttype werkt. Ik heb een methode ontwikkeld die mijn ellende heeft opgelost en ik denk dat het ook de jouwe zal oplossen.
Nu ik ben begonnen met het creëren van meer premium WordPress-thema's, ben ik begonnen met het ontwikkelen van een basisthema als een soort raamwerk om op voort te bouwen met elk nieuw project. Het proces verliep goed totdat ik met aangepaste berichttypen begon te werken. Dat is toen ik onvermijdelijk ging tegen mijn oude tijd vijand, aangepaste post type paginering.
Sinds de release van aangepaste berichttypen in WordPress 2.9 is de paginering moeilijk gebleken, afhankelijk van de omstandigheden. Zelfs hardwerkende WordPress-professionals zijn van tijd tot tijd vastgelopen.
Gelukkig voel ik dat ik eindelijk eens post-paginering op maat heb verslagen. Ik stel me voor dat ik erover buig in de gloed van het maanlicht, mijn gezicht vol gebeiteld, een voet geplant op de grond en de andere stevig op zijn borst.
Mijn sleutel tot eenvoudige aangepaste paginering van het posttype is het gebruik van de archief-posttype.php sjabloon om iets te doen dat ik chaining noem, wat betekent dat we ze gebruiken zoals inbegrepen in andere WordPress-sjabloonbestanden waar paginering nodig is. Wat dit doet, wordt beperkt door aangepaste ontwikkeling voor verschillende omstandigheden waarin een ontwikkelaar paginering wenst. Zie het als het gebruik van de archiefsjabloon van het type aangepast type als een index of alles bij elkaar. Er zijn een paar wendingen onderweg, maar dat is het grote idee. Laten we beginnen.
Omdat coderen een fundament is, laat de wetenschap maar beginnen met de kwestie van paginering zelf. Hoewel ik me buig voor de grootheid van de paginering-plugin, WP PageNavi, zoals Jacob Goldman onlangs opmerkte, is er echt geen noodzaak voor. WordPress heeft zijn eigen paginatie-functie paginate_links () en blijkbaar weten de meeste ontwikkelaars er niets van. Zorg ervoor dat je de documentatie leest, maar om je de tijd te besparen dat je je eigen code gaat maken functions.php hier is de mijne vergelijkbaar met het Codex-voorbeeld:
Accentsconagua
functie paginate () global $ wp_query, $ wp_rewrite; $ wp_query-> query_vars ['paged']> 1? $ current = $ wp_query-> query_vars ['paged']: $ current = 1; $ pagination = array ('base' => @add_query_arg ('page', '% #%'), 'format' => ", 'total' => $ wp_query-> max_num_pages, 'current' => $ current, 'show_all' => true, 'type' => 'plain'); if ($ wp_rewrite-> using_permalinks ()) $ pagination ['base'] = user_trailingslashit (trailingslashit (remove_query_arg ('s', get_pagenum_link (1)) ). 'page /% #% /', 'paged'); if (! empty ($ wp_query-> query_vars ['s'])) $ pagination ['add_args'] = array ('s' => get_query_var ( 's')); echo paginate_links ($ paginering); Mijn ketenmethode is ontwikkeld met deze functie in gedachten. Het gebruik van WP PageNavi voor aangepaste paginering op paginatype wordt echt lelijk, dus ik zal je niet laten zien hoe je dat moet doen om dezelfde reden dat vrienden geen dronken mensen laten rijden. Graag gedaan. Maar laten we verdergaan met waar je echt voor bent gekomen - eindelijk uitzoeken hoe je paginering op basis van een aangepast type kunt behouden door een 404 te gooien of altijd terug te keren naar pagina één.
Aangepaste berichttypen hebben geen eigen indexpagina's, en zoals ik al eerder zei, denk ik aan de archief-posttype.php sjabloon als zijn standaard omdat ik het gebruik als de basis voor paginering in alle andere sjablonen. Veel ontwikkelaars zullen eerst een paginasjabloon benadrukken als een indexpagina, maar 1.) Ik ben het hier duidelijk niet mee eens 2.) we komen daar later op terug. Zelfs WordPress-superster Justin Tadlock is het erover eens dat aangepaste berichttypen op zijn minst de optie van hun eigen indexpagina's moeten hebben.
Gelukkig functioneert mijn paginate () functie uit de doos met de archief-posttype.php sjabloon. Oef. Maar het probleem is dat de paginering gebonden is aan de instelling voor berichten per pagina in Instellingen> Lezen. En omdat aangepaste berichttypen precies dat zijn, zal negen keer op tien een ontwikkelaar willen dat hun berichten per pagina ook aangepast zijn. Om dit te doen, is de eenvoudigste manier om een filter op te schrijven functions.php zoals dit:
function portfolio_posts_per_page ($ query) if ($ query-> query_vars ['post_type'] == 'portfolio') $ query-> query_vars ['posts_per_page'] = 1; return $ query; if (! is_admin ()) add_filter ('pre_get_posts', 'portfolio_posts_per_page'); Deze methode kwam tot mij via het bericht van Jonathan Christopher, genaamd WordPress-berichten per pagina per aangepast berichttype. Bedankt, Jonathan!
Wat gebeurt er als ik niet wil dat mijn permalink-structuur dezelfde naam heeft als mijn aangepaste berichttype (bijvoorbeeld http://company.com/portfolio/)? Ik ben blij dat je het vraagt. Dit is een van de redenen waarom een ontwikkelaar liever een paginasjabloon gebruikt om zijn aangepaste berichttypen weer te geven. Het geeft de gebruiker volledige controle over de permalink-structuur, omdat deze eenvoudig de naam van de pagina kan wijzigen die die paginasjabloon gebruikt. Dat is begrijpelijk en dat zullen we snel doen, maar voor degenen onder ons die dat niet nodig hebben of op een andere manier in de toekomst willen is er een kleine bewerking die we onder de motorkap kunnen maken om die structuur naar onze wil te buigen.
De functie voor het maken van een aangepast berichttype, register_post_type (), accepteert een argument dat herschrijven wordt genoemd. De waarde van dat argument wordt doorgegeven als een array en het wijzigen van de waarde van de slug verandert de permalink-structuur. Hier is een voorbeeld:
'rewrite' => array ('slug' => 'insertyourpermalinknamehere', 'with_front' => true), Nadat je dit hebt gewijzigd, ga je naar Instellingen> Permalinks en klik je op de knop "Wijzigingen opslaan" om je herschrijfcache te dumpen. Ga naar uw site en vernieuw de pagina om de wijziging te bekijken. Klaar en klaar. Nogmaals, het enige nadeel van deze methode is dat niet-technische gebruikers de naam van hun permalink-structuur niet van de beheerders-GUI kunnen veranderen, tenzij ze natuurlijk op weg zijn naar de thema-editor om die herschrijfslak te veranderen..
Het is niet ongebruikelijk voor ontwikkelaars om hun aangepaste berichttypen in een statische voorpagina weer te geven en te pagineren door middel van een paginasjabloon. De reden hiervoor is tweeledig; het geeft de gebruiker de naamveranderingscapaciteiten die we zojuist besproken hebben en stelt hen in staat aangepaste berichttypen weer te geven op de voorpagina van hun site. Maar dingen kunnen hier lelijk worden. Ik schaam me om te zeggen dat ik op een bepaald moment drie verschillende manieren van aangepast post-type paginering heb gecodeerd. Dit is gedeeltelijk te wijten aan het gebruik van WP PageNavi, maar ik bezit dit genante feit om te benadrukken dat dit hele proces overweldigend kan zijn voor thema-ontwikkelaars die niet in "the know" zijn.
Laten we onze paginasjabloon bellen page-portfolio.php om de naamgevingsconventie voor sjablonen voor aangepaste berichttypen overeen te laten komen, ook al is deze niet hetzelfde. Hier is de code:
/ * Sjabloonnaam: Portfolio * / $ paged = 1; if (get_query_var ('paged')) $ paged = get_query_var ('paged'); if (get_query_var ('page')) $ paged = get_query_var ('page'); query_posts ('& post_type = portfolio & paged ='. $ paged); require_once ('archive-portfolio.php'); Dit is de eerste keer dat u de archief-posttype.php sjabloon geketend aan een andere sjabloon. En het werkt! Maar wat is er in godsnaam aan de hand? Deze janky $ paged variabele business benadrukt het exacte probleem dat ontwikkelaars lijken te hebben met aangepaste post type paginering. Als deze fix (hoest) niet op zijn plaats zit en een gebruiker klikt om pagina 2 te bekijken, net als iemand die over het hoofd is geduwd, raakt WordPress in de war en weet niet waar het zich bevindt. En om nog erger te maken, blijkbaar weet WordPress dit en accepteert het als normale ontwikkelingsprocedure door deze notitie te publiceren in de sectie Pagineringparameters van de Codex-pagina voor WP_Query ():
Paginering Opmerking: stel get_query_var ('page') in; als u wilt dat uw zoekopdracht met paginering werkt. Sinds WordPress 3.0.2 krijg je get_query_var ('page') in plaats van get_query_var ('paged'). De pagineringparameter 'paged' voor WP_Query () blijft hetzelfde.
Het is logisch dat ontwikkelaars in staat zijn om die variabele in te stellen en naar een specifieke pagina te verwijzen. Wat niet logisch is, is waarom paginering inherent werkt met standaard berichttypen (zoals post, pagina, bijlage), maar niet met aangepaste postsoorten.
Voorbij het moeten patchen van de code is er nog een andere catch hier, dat je je Page slug niet hetzelfde kunt noemen als je custom post type slug. Denk aan uw aangepaste berichtenslak als gereserveerde sleutelwoord; U kunt de titel van uw pagina echter dezelfde naam geven als uw aangepaste berichtenslak, net zo lang als uw paginaknop iets anders is.
De ... gebruiken front-page.php sjabloon vergrendelt gebruikers in een aangepaste voorpagina zonder de mogelijkheid om het te wijzigen (tenzij ze het bestand verwijderen of het tijdelijk hernoemen). Daarom kiezen de meeste ontwikkelaars voor de paginasjabloonmethode voor het maken van statische voorpagina's, maar laten we omwille van mijn methode zeggen dat we de eerste gebruiken. Om een aangepaste paginering van het posttype voor deze sjabloon te bereiken, hoeven we alleen maar op te nemen waarvoor we hebben gedaan archief-posttype.php zoals dit:
require_once ('page-portfolio.php'); De taxonomie-posttype-taxonomy.php sjabloon werkt op vrijwel dezelfde manier als de front-page.php sjabloon, maar in plaats van de page-portfolio.php sjabloon, neemt u in plaats daarvan onze index op, archief-posttype.php, zoals dit:
require_once ('archive-posttype.php'); Dat maakt de omvang van mijn methode compleet. Waar ik eens in de ochtend om twee uur met mijn hoofd tegen het bureau sloeg, loop ik nu kalm door projecten om twee uur 's middags. Zege! Nou ja, althans voor nu. Ik ben niet zo naïef om te denken dat ik mezelf misschien niet zal vinden in een situatie waarin deze methode niet werkt voor aangepaste paginering van het posttype, maar ik heb dit nog niet gedaan.
In tegenstelling tot mijn andere berichten hoop ik dat deze wordt verouderd. Ik hoop dat WordPress zal reageren op de recente enquête waaruit blijkt dat 92% van alle ontwikkelaars WordPress als een CMS gebruiken en een tweede blik werpen op hoe paginering werkt op hun platform. Het team van WordPress is niets minder dan professioneel. Ik stel me een toekomst voor waarin er ingebouwde pagineringstools en mogelijk een aangepaste admin-pagina van het posttype zijn onder Instellingen voor het beheren van berichten per pagina per aangepast berichttype. Maar voor nu hoop ik dat deze ketenmethode de vele ontwikkelaars helpt die ik heb zien lijden op de WordPress Forums. Aarzel niet om de volgende gecomprimeerde bestanden te downloaden, te gebruiken en te misbruiken als een raamwerk voor succesvolle paginering van het aangepaste posttype. Genieten!
