Shared cPanel klanten: de vier soorten en wat ze nodig hebben

Een bureau-eigenaar uit Rotterdam stuurde vorige dinsdag om 23:41 een Loom. De thumbnail liet een cPanel File Manager zien, geopend op public_html, met vier geneste WordPress-installaties in /old, /old2, /staging en /staging-final, en een Post-it op de hoek van het bureau met de tekst 'niet aanraken'. De klant had de hosting overgenomen van de vorige webbouwer, die het op zijn beurt weer had overgenomen van het bureau daarvoor. Iedereen wilde eruit. Niemand wilde degene zijn die de site op een vrijdag uit de lucht trok.

Als je in 2026 nog klantwerk doet, kom je deze accounts steeds tegen. Niet wekelijks, maar vaak genoeg dat een mentale kaart je elke keer een uur bespaart. Er leven nu ruwweg vier soorten klanten op shared cPanel, en zodra je weet wie er aan de andere kant van de mail zit, wordt de rest van het gesprek korter.

De brochuresite van de buurtwinkel

Vijf pagina's, een contactformulier, een Google Maps-embed, en een footer waar nog steeds '© 2018' staat. Gebouwd door iemands neef die WordPress heeft geleerd via een YouTube-serie. Hij laadt in twee seconden, scoort op de naam van de eigenaar, en levert misschien één aanvraag per week op. De omzet uit de website is reëel maar wordt niet gemeten.

Wat deze klant denkt nodig te hebben: een herbouw op Next.js, omdat het bureau aan tafel bij de Rotary-lunch zei dat WordPress 'uit' is.

Wat ze werkelijk nodig hebben: de brakke contactformulier-plugin vervangen voordat de host gedwongen upgradet naar PHP 8.3 en mail() stukmaakt op een manier die zes weken lang niemand opmerkt. De rest van de verouderde site is prima. PHP's eigen supportkalender heeft 8.1 al uit security fixes staan; de host verhuist ze wanneer de host wil, niet wanneer zij willen.

Het juiste werk kost twee uur. Vervang de verlaten formulier-plugin door iets wat onderhouden wordt, zet een SMTP-plugin op zodat mail het pand ook echt verlaat, en vertel de eigenaar dat de cookiebanner inmiddels een wettelijke verplichting is, geen stijlkeuze.

De WooCommerce-winkel die de huur betaalt

Jaaromzet tussen veertig- en driehonderdduizend euro, vrijwel alles via een WooCommerce-installatie op een hostingpakket van twintig euro. PHP staat vastgepind op 8.0 omdat de payment gateway-plugin daarboven kapotgaat. De ordertabel telt tachtigduizend rijen. wp_options is veertig megabyte, voornamelijk verlopen transients die niemand heeft opgeruimd.

Wat deze klant denkt nodig te hebben: een migratie naar Shopify, omdat het neefje van de boekhouder dat zei.

Wat ze werkelijk nodig hebben: een pre-flight op wat ze al hebben. Welke plugins zijn verlaten. Welke custom functie in functions.php is de reden dat een 'simpele' upgrade telkens faalt. Of de gateway-plugin een opvolger heeft, of dat ze in de kou komen te staan zodra de host PHP de volgende keer geforceerd upgradet.

De eerste nuttige query duurt dertig seconden en vertelt je het meeste over de database:

SELECT option_name, LENGTH(option_value)/1024 AS kb
FROM wp_options
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Als de bovenste rij een geserialiseerde blob is van een plugin die de klant twee jaar geleden heeft gedeïnstalleerd, heb je je middag gevonden. De Magento 1 EOL-golf leerde iedereen dezelfde les: een rustige winkel op een oude stack kan jaren draaien, tot het moment dat de host of de gateway een verhuizing forceert op een planning die niet de jouwe is.

Het reseller-pakket met twintig mysterieuze sites

Een eenmansstudio die je al tien jaar kent draait een reseller-account bij één van de grotere Europese hosters. Twintig cPanel-accounts eronder. Acht zijn live en factureren vijftien euro per maand. Zes zijn verlaten maar serveren nog. Vier zijn staging-kopieën van dezelfde Drupal 7 site uit 2017. Twee zijn iets dat niemand bij de studio kan identificeren.

Wat de eigenaar denkt nodig te hebben: een junior die de hosting-admin overneemt zodat hij eindelijk op vakantie kan.

Wat ze werkelijk nodig hebben: een inventarisatie. PHP-versie, CMS-versie, laatste login, laatste file mtime, laatste back-up. Een spreadsheet, geen refactor. Op de meeste cPanel-hosts wordt de PHP-versie per site door MultiPHP Manager in .htaccess geschreven, wat betekent dat je de eerste kolom in één keer over SSH kan produceren:

for d in /home*/*/public_html; do
  ver=$(grep -hoE 'ea-php[0-9]+' "$d/.htaccess" 2>/dev/null | head -1)
  echo "$d => ${ver:-host-default}"
done

De helft van de accounts wordt uitgezet zodra de eigenaar de lijst ziet. De andere helft wordt een kleine, factureerbare onderhoudsregel.

De overgenomen portfolio zonder overdracht

Het bureau heeft een ander bureau gekocht, of de lead developer is opgestapt en heeft zijn hoofd meegenomen. Dertig tot tachtig cPanel-accounts staan nu in een map met het label 'old client hosting' die niemand opent. Elke site heeft een net iets andere ACF-versie, een net iets ander parent theme, een net iets andere SMTP-plugin, en een wp-config.php die bijna werkt.

Wat de nieuwe eigenaars denken nodig te hebben: alles migreren naar een 'moderne stack' voor het einde van het kwartaal.

Wat ze werkelijk nodig hebben: triage en een kill list. Welke sites factureren nog. Van welke sites denkt de oorspronkelijke klant nog steeds dat ze er zijn. Welke draaien een WordPress core-versie die oud genoeg is om een security-incident in wording te zijn. Daarna, en pas daarna, een migratieplan voor het derde van de portfolio dat de moeite waard is.

Het patroon is bij alle vier de soorten hetzelfde. De klant heeft geen herbouw nodig. Ze hebben iemand nodig die de bestaande stack kan openen, kan zien wat er werkelijk staat, drie kleine dingen kan wijzigen, en een helder spoor achterlaat van wat er is veranderd en waarom.

De gemene deler

Eerst lees-toegang, daarna nauwsluitende schrijfrechten. Een werkende .htaccess die de site geen 500 geeft als je hem opslaat. Een manier om een rij in wp_options te bewerken zonder elke zes maanden de eigenaardigheden van phpMyAdmin opnieuw te leren. Versiegeschiedenis op elke tekstwijziging, want zodra er op een vrijdag iets stukgaat is de enige vraag die telt: welke regel is verschoven.

Toen we Pier voor dit soort werk bouwden, kwamen we steeds terug bij de MySQL editor. De meeste echte schade op shared cPanel-accounts ontstaat door één onvoorzichtige update op wp_options of een geserialiseerde optie die niemand kan terugdraaien, en dat versioneren met een ondoen-toets bleek nuttiger dan alles wat we slimmer probeerden te bouwen.

Het kleinste wat je vandaag kan doen: open het oudste cPanel-account in je portfolio en schrijf twee getallen op. De PHP-versie die erop draait. De WordPress-, Drupal- of Joomla core-versie die erop draait. Dat is het begin van de audit die je sinds januari aan het uitstellen bent.