De nachtmerrie die wp-cron.php is

BY admin
|

Een grote ergernis die ik heb met WordPress is de standaard wp-cron.php implementatie. Als u bekend bent met hoe WordPress wp-cron.php standaard gebruikt, kunt u misschien beter verder gaan naar het volgende gedeelte van dit artikel.

Het bestand wp-cron.php is het gedeelte van WordPress dat de geplande gebeurtenissen binnen een WordPress site afhandelt. Alles wat te maken heeft met het plannen van berichten of publicaties en eigenlijk alles wat datum / tijd georiënteerd is, wordt geregeld door het wp-cron.php bestand.

Om wp-cron.php goed te laten werken, moet het regelmatig worden uitgevoerd, maar niet meer dan een keer per minuut. Echter, het standaard gedrag vereist niet dat u een echte systeem-niveau cron job op uw server instelt. In plaats daarvan gebruikt het een piggyback methode op elk inkomend verzoek. Wanneer een verzoek binnenkomt op de site, zal WordPress een extra verzoek van zichzelf genereren naar het wp-cron.php bestand over HTTP(S). Dat klinkt vrij onschuldig, toch?

Waarom is het standaard wp-cron.php gedrag een nachtmerrie?

De standaard methode werkt prima op een kleine site met zeer weinig bezoekers per uur. Echter, wanneer geïmplementeerd op een middelgrote of grotere site of zelfs een site die wordt gescand door bots (wat heel gebruikelijk is deze dagen), betekent dit dat je twee keer zoveel verkeer krijgt als je op dit moment verwerkt. Het wordt een rudimentaire DDoS-aanval tegen jezelf. Dit komt omdat de cron meerdere keren per minuut wordt uitgevoerd met een HTTP verzoek. Het HTTP verzoek genereert extra overhead door het moeten genereren, onderhandelen en tot stand brengen van de verbinding over een netwerk socket. Het beïnvloedt zelfs de effectieve capaciteit van je onderliggende webserver. Deze oplossing doet het niet goed in de meeste situaties, en eerlijk gezegd, het moet worden verwijderd als de standaard gedrag te wijten aan zijn neiging om te worden misbruikt of omgezet in een aanval vector op een server alleen van gewone verkeer.

Wel, wat zijn de alternatieven?

Het enige echte alternatief en de veel betere oplossing is het configureren van een reguliere systeem cronjob dat het wp-cron.php script rechtstreeks via PHP elke minuut uitvoert. Dit zorgt ervoor dat alle geplande taken inderdaad worden uitgevoerd op de geplande tijd. Het moet ook niet worden gedaan via een HTTP-verzoek, maar een directe uitvoering van PHP om te voorkomen dat het belemmeren van de webserver capaciteit of het genereren van extra geheugen overhead op de netwerklaag.

Hoe kan ik uitschakelen van de standaard wp-cron.php gedrag?

Dit is vrij universeel en eenvoudig te doen. U moet uw wp-cronfig.php bestand bijwerken om de volgende instelling op te nemen:

define('DISABLE_WP_CRON', true);
  • U kunt uw wp-config.php bestand meestal vinden in de public_html directory van uw site.
  • Deze nieuwe instelling moet in het bestand worden gezet net na de DB_COLLATE database regel die er als volgt uitziet
define('DB_COLLATE', '');

Hoe stel ik een systeem cron job in?

Dit is eenvoudig in cPanel, ervan uitgaande dat uw hosting provider de cron job functie heeft ingeschakeld op uw account. De cPanel Cron Jobs Documentatie gaat in meer details, maar in wezen doe je:

  1. Login op cPanel voor uw domein: yourdomain.tld/cpanel
  2. Invoer “cron” in de snelle zoekvak bovenaan de pagina.
  3. Klik op “Cron Jobs” icoon dat verschijnt.
  • Als het niet verschijnt, heeft uw account niet de Cron Jobs-functie ingeschakeld en moet u met uw hostingprovider praten voor hulp bij het instellen van de cron of overschakelen naar een pakket dat de Cron Jobs-functie bevat.
  1. Let op de Cron Jobs-pagina, deze zal u de exacte locatie van uw PHP binary geven. U moet dat pad kopiëren naar het opdrachtvak onderaan de pagina en het bestand dat door PHP wordt uitgevoerd wijzigen in uw /home/gebruikersnaam/public_html/wp-cron.php bestand. Gebruik het volledige pad.
  2. Selecteer het eerste item (“*”) voor elke parameter. Dit zal het wp-cron.php bestand elke minuut uitvoeren.
  3. Klik op de add cron knop en je bent klaar.

Waarom ben je zo hard voor deze praktijk, het lijkt redelijk en eenvoudig te verhelpen?

Ik geloof dat het aan de software ingenieurs is die onze digitale wereld ontwikkelen om zichzelf een gevoel van verantwoordelijkheid voor hun producten op te leggen. WordPress is alomtegenwoordig deze dagen en met auto installer software, zoals Softaculous, wordt WordPress geïnstalleerd op een zeer grote meerderheid van sites. Ze worden geïnstalleerd met het standaard gedrag ingeschakeld, wat in wezen een aanvalsvector is op elke server. Nu de hosting industrie zo wijdverbreid is in ons leven, hebben veel mensen WordPress sites en weten niet van dit probleem totdat het hun site lamlegt. De standaard integratie is zeer ontoereikend en zou verwijderd moeten worden. Vandaag vond ik alleen al op één server meer dan 500 verschillende installaties van WordPress en zag ik hoe een bot elke site op de server aanviel. Elk van die sites werd plotseling een gevaar voor de stabiliteit van de server.

Ik realiseer me dat dit probleem van geval tot geval wordt bekeken. Echter, met zo veel installaties over de hele wereld, zou het beter worden aangepakt door WordPress in plaats van elke afzonderlijke hosting provider die speciale voorwaarden op hun server moet instellen om te beschermen tegen het gat dat deze software genereert. De kosten van het verwijderen van dit gedrag en het dwingen van site-eigenaren om een systeem cron te genereren zou een basislijn moeten zijn en een mededeling geplaatst in de WordPress admin interface dat geplande taken niet zullen worden uitgevoerd totdat een systeem cron job correct is aangemaakt. Dit is binnen mijn programmering vaardigheden, dus ik weet dat het goed binnen hun.

WordPress is gericht op gebruiksgemak, dus hun doelgroep zijn degenen die meestal weinig weten over hosting caveats. Ik denk dat de verantwoordelijkheid hier ligt volledig bij WordPress te repareren en zij hebben het standpunt tegen het. In de tussentijd moeten de systeembeheerders in de hosting-industrie lijden onder deze vreselijke “functie” bij het onderzoeken van servers die uit de hand zijn gelopen als gevolg van een bot die over een standaard WordPress-installatie loopt.