Share
Als een van de minder gebruikte WordPress-functies wordt WP-Cron vaak over het hoofd gezien door ontwikkelaars. De toepassingen ervan zijn echter geen gelach. Van caching tot meldingen om op te ruimen, het plannen van cron-taken kan werken om een duidelijk voordeel te creëren in zelfs het meest eenvoudige WordPress-blog. Doe mee met het verkennen van belangrijke applicaties van ditzelfde systeem.
WP-Cron is niet hetzelfde als de Unix cron-planner?
Meteen bij het zien van het woord cron, Ik ben er zeker van dat je een punt hebt gemaakt waar we naar toe gaan: het plannen van perfect getimede gebeurtenissen om met bepaalde intervallen te worden uitgevoerd. Integendeel, WP-Cron is niet hetzelfde als de Unix cron-scheduler. Het belangrijkste onderscheid ligt in hoe het wordt uitgevoerd; in tegenstelling tot een achtergrondproces, begint WP-Cron elke keer dat een bezoeker je WordPress-site opent. Als zodanig behoudt het de essentiële eigenschap van onnauwkeurige timing.
Ja, je leest het goed: onnauwkeurige timing. Hoewel de woorden cron en nauwkeurigheid als twee erwten in een pod zijn, harmoniseren ze niet in het WordPress-systeem. Maar is dit echt een probleem? Als dit in de context van de gebruiker wordt beschouwd, wordt dit feitelijk een voordeel.
Laten we het voorbeeld nemen van een normale cron-taak die elke vijf minuten wordt uitgevoerd om een aantal database-informatie bij te werken die op een website wordt gebruikt. Als geen bezoekers de site 40 minuten bezoeken, wat is dan het nut om deze taak acht keer uit te voeren? Alle tussenwaarden zouden beide verouderd en ongebruikt zijn. Als het omgekeerd het eerste bezoek van de gebruiker zou starten na minimaal vijf minuten, zou het niet alleen dezelfde taak uitvoeren, maar ook onnodige updates voorkomen. Met andere woorden, omdat WP-Cron gebaseerd is op de gebruiker, heeft het het voordeel dat het alleen draait wanneer bezoekers aanwezig zijn.
Om WP-Cron toe te passen, laten we eens kijken naar de vaak gebruikte RSS-beheerapp, FeedBurner. Verreweg een van de meest populaire functies van deze applicatie is de mogelijkheid om RSS-abonnees te tellen. Eenmaal geïndexeerd, kan het aantal abonnees van een site worden benaderd via een eenvoudige API-aanroep. Hieruit volgt dat deze API-aanroep eenmaal per paginaweergave kan worden uitgevoerd om het aantal abonnees aan kijkers te leveren. Dit leidt echter tot een probleem.
Als de API van FeedBurner eenmaal per paginabezoek wordt geopend, leidt dit onvermijdelijk voor elke bezoeker tot een extra HTTP-verzoek - om niet te zeggen een uit een ander domein. Dit verhoogt de laadtijd van de pagina voor gebruikers.
Om dit probleem tegen te gaan, is het belangrijk om één belangrijke realisatie te maken over deze bezorgmethode: een RSS-aantal abonnees zal waarschijnlijk niet bij elke weergave van de pagina worden bijgewerkt. FeedBurner werkt zijn telling slechts eenmaal per dag bij. Zelfs als het snel zou veranderen, is het dan echt nodig om de laatste telling voor elke bezoeker weer te geven? Maakt het uit dat de telling enigszins verouderd is, maar vervolgens binnen een dag is opgefrist?
Voor onze doeleinden is het volledig nutteloos om het aantal RSS-abonnees voor elke paginaweergave te achterhalen. In plaats daarvan kan het, als het voor één bezoeker wordt opgehaald, eenvoudig worden hergebruikt voor toekomstige bezoekers. Na een dag kan een update voor deze telling worden gemaakt. Zo'n proces staat bekend als caching. Nadat het aantal RSS-abonnees is bijgewerkt, wordt het opgeslagen in de cache - opgeslagen voor toekomstig gebruik in plaats van opnieuw te worden berekend - tot een dag is verstreken. En daarmee betreden we de wereld van WP-Cron.
Om WP-Cron te begrijpen, is het belangrijk om te weten waar documentatie beschikbaar is. WordPress.org biedt samenvattingen van elke cron-functie in zijn Codex. Om onze eerder gedefinieerde taak te voltooien, moeten we kijken naar de wp_schedule_event functie, waarvoor vier parameters nodig zijn:
Ons evenement wordt geactiveerd wanneer de huidige tijd de tijd verstreken of overschrijdt die aan deze functie is doorgegeven, zoals voorgeschreven door een toekomstige bezoeker van de website. Vervolgens wordt opnieuw getriggerd op basis van de parameter herhaling, die kan worden ingesteld op uurlijks, twindelijks, dagelijks of geen uur. Aangepaste herhalingsschema's kunnen ook worden gedefinieerd.
Om met de gebeurtenis om te gaan, wordt een haak gebruikt. Kortom, een WordPress-haak kan worden beschouwd als een tijdelijke aanduiding voor een actie. Acties kunnen worden toegewezen aan hooks via WordPress ' add_action functie. Meer specifiek, om een functie-handler aan de gegeven haak toe te voegen, kan men bellen:
Accentsconagua
add_action ('hook_name', 'function_name'); waarbij hook_name en function_name respectievelijk de naam zijn van de hook and handling-functie.
Omdat FeedBurner eenmaal per dag wordt bijgewerkt, zullen we een dagelijks schema opgeven, volgens de onderstaande code:
wp_schedule_event (time (), 'daily', 'feedburner_refresh');
Let daar op tijd() is het huidige UNIX-tijdstempel in seconden. Als het wordt uitgevoerd, wordt de haak 'FeedBurner-update' onmiddellijk geactiveerd en daarna één keer per dag daarna. Merk op dat als we dit gewoon in ons WordPress functions.php-bestand zouden plaatsen, het een nieuwe gebeurtenis zou plannen bij elke lading van een enkele pagina. Dit is niet onze gewenste functionaliteit; integendeel, we willen dit evenement slechts één keer plannen. De eenvoudigste manier om dit te doen, is door simpelweg te controleren of de gebeurtenis al is gepland. Dit kan worden gedaan via de wp_next_scheduled functie, die false retourneert als de gebeurtenis niet is ingesteld om in de toekomst te triggeren of de tijd van de volgende trigger anders:
if (! wp_next_scheduled ('feedburner_refresh')) wp_schedule_event (time (), 'daily', 'feedburner_refresh'); Als we deze gebeurtenis ooit ongedaan moeten maken, is het net zo eenvoudig als het oproepen van de wp_unschedule_event functie, die dezelfde parameters neemt, behalve de herhaling, als wp_schedule_event. Merk op dat de verstreken tijd de tijd moet zijn van de volgende trigger, die via kan worden opgehaald wp_next_scheduled:
if (false! == ($ time = wp_next_scheduled ('feedburner_refresh'))) wp_unschedule_event ($ time, 'feedburner_refresh'); We kunnen deze gebeurtenis ook ongepland maken via de haaknaam met behulp van de wp_clear_scheduled_hook functie. Houd er rekening mee dat dit alternatief ook alle andere evenementen met dezelfde hook verwijdert.
wp_clear_scheduled_hook ('feedburner_refresh'); 
Nu ons evenement is gepland, moeten we er een handler aan toevoegen:
add_action ('feedburner_refresh', 'update_rss_subscriber_count'); Hiermee wordt de functie met de naam ingesteld update_rss_subscriber_count te worden genoemd zodra de feedburner_refresh haak wordt getriggerd. Het is nu tijd om deze functie te schrijven.
Om het aantal abonnees op te halen in de update_rss_subscriber_count functie, kunnen we via de URL bellen naar de API van FeedBurner
Hiermee worden XML-gegevens geretourneerd in de volgende vorm:
De informatie waarnaar we op zoek zijn, bevindt zich in het kenmerk circulatie. De volgende reguliere expressie kan eenvoudig door de gegevens voor deze waarde bladeren: circulatie = "(. *?)".
In het Engels komt onze reguliere expressie overeen met het volgende:
circulatie = - Het woord circulatie gevolgd door een gelijkteken"(. *?)" - Citaten en alles erin Dit uitvoeren met behulp van de preg_match functie haalt een reeks overeenkomsten op die het aantal abonnees op de eerste indexpositie bevatten. Als u deze informatie bij elkaar optelt, krijgt u de volgende code:
// zoek de FeedBurner-URL en haal de gegevens ervan op // wijzig [NAME] in de naam van uw FeedBurner-feed $ url = 'https://feedburner.google.com/api/awareness/1.0/GetFeedData?uri= [ NAAM]'; $ data = @file_get_contents ($ url); // @ zal fouten verdringen // gebruik een reguliere expressie om de gegevens te ontleden $ regex = '% circulation = "(. *?)"%'; preg_match ($ regex, $ data, $ matches); // krijg de resulterende telling indien beschikbaar $ count = false; if ($ matches && $ matches [1]) $ count = (int) $ wedstrijden [1];
Nu we het aantal abonnees hebben opgehaald, moeten we het opslaan voor toegankelijkheid; in plaats van de API XML-gegevens opnieuw te bekijken, hebben bezoekers alleen toegang tot deze opgeslagen waarde.
In plaats van een database of bestand voor opslagdoeleinden te maken, kunnen we nog een andere WordPress-functie gebruiken: opties. WordPress-opties zijn eenvoudige manieren om databits samen met identificerende namen op te slaan. Opties toevoegen, verwijderen en openen zijn net zo eenvoudig als de volgende functies:
update_option ($ naam, $ waarde) - Voegt een optie met naam toe of update deze name $ en waarde $ value.delete_option ($ naam) - Verwijder een optie met naam name $.get_option ($ naam) - Verkrijg de optiewaarde die is gekoppeld aan naam name $. Hoewel ons aantal abonnees technisch gezien geen configuratiewaarde is, is het gebruik van WordPress-opties een van de handigste manieren om dergelijke eenvoudige gegevens op te slaan, zo niet de handigste. Om het aantal abonnees op te slaan, gebruiken we de update_option methode, die niet alleen de vorige waarden zal overschrijven, maar ook de optie op de eerste plaats maakt:
// als er geen telling kon worden gevonden, update // dan niet, maar blijf bij de vorige telling als ($ count! == false) update_option ('subscriber_count', $ count); Onze functie is voltooid! Na het instellen van de gebeurtenis, het terughalen van de gegevens via de FeedBurner API en het opslaan van de gewenste waarde, is alles wat u hoeft te doen uitgevoerd! De volledige code voor de plannings- en opvraagfunctie, die u in functions.php kunt plaatsen, vindt u hieronder:
// plan de feedburnerer_refresh-gebeurtenis slechts een keer als (! wp_next_scheduled ('feedburner_refresh')) wp_schedule_event (time (), 'daily', 'feedburner_refresh'); add_action ('feedburner_refresh', 'update_rss_subscriber_count'); function update_rss_subscriber_count () // zoek de FeedBurner-URL op en verkrijg de gegevens ervan // wijzig [NAME] in de naam van uw FeedBurner-feed $ url = 'https://feedburner.google.com/api/awareness/1.0/ ? GetFeedData uri = [NAME] '; $ data = @file_get_contents ($ url); // @ zal fouten verdringen // gebruik een reguliere expressie om de gegevens te ontleden $ regex = '% circulation = "(. *?)"%'; preg_match ($ regex, $ data, $ matches); // krijg de resulterende telling indien beschikbaar $ count = false; if ($ matches && $ matches [1]) $ count = (int) $ wedstrijden [1]; // als er geen telling kon worden gevonden, update // dan niet, maar blijf bij de vorige telling als ($ count! == false) update_option ('subscriber_count', $ count); Het aantal abonnees is nu slechts een functieoproep verwijderd in elk sjabloonbestand:
echo get_option ('subscriber_count'); 
Ons aantal RSS-abonnees is nu geoptimaliseerd; in plaats van dat het wordt opgehaald voor elke aanvraag, wordt het opgeslagen in de cache met de hulp van WP-Cron, waardoor onze gebruikers tijd besparen en het bandbreedtegebruik verminderen. Omdat het alleen wordt geactiveerd wanneer onze site daadwerkelijk een bezoeker ontvangt, is onze functie lui, een term die in deze context zeker als goed kan worden beschouwd. Maar helaas hebben we hier maar één toepassing van WP-Cron onthuld; de rest is aan jou.
Heb je een eigen innovatieve toepassing van WP-Cron? Deel het met ons in de comments!
