Mareridtet wp-cron.php

BY admin
|

Et af mine største problemer med WordPress er standardimplementeringen af wp-cron.php. Hvis du er bekendt med, hvordan WordPress bruger wp-cron.php som standard, kan du måske springe videre til næste afsnit i denne artikel.

Filen wp-cron.php er den del af WordPress, der håndterer planlagte begivenheder på et WordPress-websted. Alt, der har at gøre med planlægning af indlæg eller publikationer og virkelig alt dato/tids-orienteret, styres af filen wp-cron.php.

For at wp-cron.php skal fungere korrekt, skal den udføres ofte, men ikke mere end en gang i minuttet. Standardadfærden kræver dog ikke, at du opretter et rigtigt cron-job på systemniveau på din server. I stedet bruger den en piggyback-metode på hver indgående anmodning. Når der kommer en anmodning ind på webstedet, genererer WordPress en ekstra anmodning fra sig selv til filen wp-cron.php over HTTP(S). Det lyder ret uskadeligt, ikke?

Hvorfor er standardadfærden i wp-cron.php et mareridt?

Den standardmetode fungerer helt fint på et lille websted med meget få besøgende i timen. Men når det implementeres på et mellemstort eller større websted eller endda et websted, der bliver scannet af bots (hvilket er meget almindeligt i disse dage), betyder det, at du får dobbelt foldet den trafik, du håndterer i øjeblikket. Det bliver et rudimentært DDoS-angreb mod dig selv. Dette skyldes, at cronen bliver udført flere gange i minuttet ved hjælp af en HTTP-forespørgsel. HTTP-anmodningen genererer yderligere overhead ved at skulle generere, forhandle og etablere forbindelsen over en netværkssocket. Det påvirker endda den effektive kapacitet af din underliggende webserver. Denne løsning klarer sig ikke godt i de fleste situationer, og ærligt talt bør den fjernes som standardadfærd på grund af dens tilbøjelighed til at blive misbrugt eller omdannet til en angrebsvektor på en server blot fra almindelig trafik.

Hvad er alternativerne?

Det eneste reelle alternativ og den meget bedre løsning er at konfigurere et almindeligt systemcronjob, der udfører scriptet wp-cron.php direkte via PHP hvert minut. Dette sikrer, at alle planlagte opgaver rent faktisk udføres på deres planlagte tidspunkt. Det bør heller ikke ske via en HTTP-forespørgsel, men en direkte udførelse af PHP for at undgå at hæmme webserverens kapacitet eller generere yderligere hukommelsesoverhead på netværkslaget.

Hvordan deaktiverer jeg standardadfærden for wp-cron.php?

Dette er ret universelt og enkelt at gøre. Du skal opdatere din wp-cronfig.php-fil, så den indeholder følgende indstilling:

define('DISABLE_WP_CRON', true);
  • Du kan typisk finde din wp-config.php-fil i dit websted i public_html-mappen.
  • Denne nye indstilling skal indsættes i filen lige efter DB_COLLATE-database-linjen, som ser ud som følgende
define('DB_COLLATE', '');

Hvordan opretter jeg et systemcronjob?

Dette er enkelt i cPanel, forudsat at din hostingudbyder har aktiveret cronjobfunktionen på din konto. Dokumentationen om cPanel Cron Jobs går mere i detaljer, men i det væsentlige gør du følgende:

  1. Log ind på cPanel for dit domæne: yourdomain.tld/cpanel
  2. Indtast “cron” i hurtigsøgningsfeltet nær toppen af siden.
  3. Klik på ikonet “Cron Jobs”, der vises.
  • Hvis det ikke vises, har din konto ikke funktionen Cron Jobs aktiveret, og du skal tale med din hostingudbyder for at få hjælp til at konfigurere cron eller skifte til en pakke, der indeholder funktionen Cron Jobs.
  1. Vær opmærksom på siden Cron Jobs, den vil give dig den nøjagtige placering af din binære PHP-fil. Du skal kopiere denne sti ind i kommandoboksen nederst på siden og ændre den fil, der udføres af PHP, til at være din /home/username/public_html/wp-cron.php-fil i stedet. Brug af den fulde sti.
  2. Vælg den første post (“*”) for hver parameter. Dette vil udføre filen wp-cron.php hvert minut.
  3. Klik på denne tilføj cron-knap, og du er færdig.

Hvorfor er du så hård ved denne praksis, den virker fornuftig og nem at løse?

Jeg mener, at det er op til de softwareingeniører, der udvikler vores digitale verden, at indprente sig selv en følelse af ansvar for deres produkter. WordPress er allestedsnærværende i disse dage, og med automatisk installationssoftware, som Softaculous, bliver WordPress installeret på et meget stort flertal af websteder. De installeres med standardadfærd aktiveret, hvilket i bund og grund er en angrebsvektor på enhver server. Nu hvor hostingbranchen er så udbredt i vores liv, har mange mennesker WordPress-websteder og kender ikke til dette problem, før det lammer deres websted. Standardintegrationen er yderst utilstrækkelig og bør fjernes. I dag fandt jeg alene på en server over 500 forskellige installationer af WordPress og så, hvordan en bot ramte hvert enkelt websted på serveren. Hvert eneste af disse websteder blev pludselig en belastning for serverens stabilitet.

Jeg er klar over, at dette problem håndteres fra sag til sag. Men med så mange installationer rundt om i verden ville det være bedre behandlet af WordPress end af hver enkelt hostingudbyder, der skal opsætte særlige betingelser på deres server for at beskytte mod det hul, som denne software genererer. Omkostningerne ved at fjerne denne adfærd og tvinge webstedsejere til at generere et systemcron-job bør være baseline og en meddelelse placeret i WordPress-administrationsgrænsefladen om, at planlagte opgaver ikke vil blive udført, før et systemcron-job er oprettet korrekt. Dette ligger inden for mine programmeringsfærdigheder, så jeg ved, at det er godt inden for deres.

WordPress sigter mod brugervenlighed, så deres målgruppe af forbrugere er dem, der typisk ved lidt om hostingforbehold. Jeg mener, at ansvaret her ligger helt og holdent hos WordPress at rette op på, og de har taget stilling imod det. I mellemtiden må systemadministratorerne i hostingbranchen lide under denne forfærdelige “funktion”, når de undersøger servere, der er faldet ud af kontrol på grund af en bot, der kører over en standard WordPress-installation.