W3Techs: dertig procent van tien miljoen populairste websites draait WordPress

W3Techs, dat het gebruik van bepaalde webtechnieken onderzoekt en bijhoudt, vermeldt in zijn recentste statistieken over contentmanagementsystemen dat dertig procent van de tien miljoen populairste websites op WordPress draait.

Het gebruik van WordPress is niet ineens heel hard gestegen, maar bereikte onlangs de mijlpaal van dertig procent, zo toont W3Techs op zijn cms-pagina. Daarmee laat het andere cms-producten ver achter zich, zoals Joomla met 3,1 procent en Drupal met 2,2 procent. Daarop volgen Magento, Shopify en Blogger. De groei van WordPress verliep volgens de W3Techs-gegevens gestaag, zo bereikte het systeem eind 2015 een aandeel van 25 procent.

Dat percentage houdt rekening met alle pagina's in de Alexa-top van de tien miljoen populairste websites, die W3Techs aanhoudt voor zijn onderzoeken. Sommige van die websites gebruiken echter helemaal geen cms dat door de organisatie wordt geteld. Als wordt gekeken naar het aandeel onder websites die wel een bijgehouden cms gebruiken, dan komt het aandeel van WordPress uit op 60 procent.

Ook de aandelen van Joomla, Drupal en andere systemen laten dan een verdubbeling zien, in dit geval respectievelijke 6,3 en 4,4 procent. De statistieken van W3Techs tonen niet de distributie in WordPress-versies. In versie 4.9.3 werd een bug in de software geïntroduceerd die automatische updates uitschakelde en daarom een handmatige update vereist voor een patch.

De opensourcesoftware kwam in 2003 uit. De volgende grote release is versie 5.0, die ergens dit jaar moet uitkomen.

Reacties (81)

Ik heb zelf jaren lang met Drupal gewerkt en ook een aantal modules voor geschreven.
Ik denk persoonlijk dat Wordpress zo veel gebruikt wordt omdat ze als één van de weinige wordpress simpel hebben weten te houden. Bij Drupal vind ik het de afgelopen jaren alleen maar complexer geworden om er iets voor te bouwen. Als je éénmaal het systeem kent is het geen probleem, maar die drempel is killing, zelfs de simpelste dingen kunnen zo moeilijk worden.

Ben ik de enige die Wordpress niet ziet als "simpel"? Mijn gebruikerservaring is veelal "bulky", "langzaam", "onoverzichtelijk". Je kan er heel veel mee (plugins), maar daardoor wordt het een stuk onoverzichtelijker.

WordPress heeft wel goede hosting nodig. Voorkant van de website kan je vaak nog wel opvangen met caching. Maar wanneer je een website hebt met veel content heb je draai je liefste je site op een eigen vps.

Ik vind frontend caching een lapmiddel voor slecht programmeerwerk. Een uitzondering hiervoor zijn sites met honderduizenden bezoekers per dag, maar een 15 pagina site voor de bakker op de hoek zou geen frontend caching nodig mogen hebben.

Als ik al hoor dat een wordpress site traag is, en dat het opgelost moet worden om Varnish er voor te zetten, en dan daar weer voor NginX, want ja, de site moet toch echt onder SSL...
Dan ben je het probleem niet aan het oplossen maar aan het wegschuiven naar operations, met een doekje voor het bloeden.

En het is heel simpel te zien, Wordpress met een goed gemaakt theme draait als een zonnetje op de allergoedkoopste hosting, pas als brakke plugins aangehaakt worden stort het als een kaartenhuis in elkaar.

Hier ben ik het niet helemaal mee eens. Uiteindelijk wordt in jouw voorbeeld een blog systeem ingezet voor een statische informatieve website. Vervolgens gaat het systeem voor elke bezoeker 130 tot 180 database verzoeken aan de Mysql server plaatsen. Het antwoord op die queries gaat de hele dag hetzelfde zijn want het was immers een statische website voor de bakker op de hoek en geen blog. Caching wordt dan ineens heel erg logisch.

De grootste kracht van WordPress is meteen het grootste nadeel. Het is zo laagdrempelig dat iedereen zichzelf tegenwoordig webdesigner kan noemen. Voor elke functionaliteit wordt er een plugin bijgehaald tot je uiteindelijk websites tegenkomt die letterlijk 200.000 extra bestanden aan plugins gebruiken.

Wat mij betreft maakt WordPress een fork gericht op het deel van de markt dat er helemaal niet op blogged. Waar dus standaard al rekening mee wordt gehouden met een vorm van rigiditeit.

Ik ben het niet met je eens dat het altijd een lapmiddel is voor slecht programmeerwerk, al sluit ik niet uit dat het als permanente oplossing ingezet wordt, zonder het onderliggende probleem op te lossen.

Wanneer de site voor elke request de pagina moet opbouwen en gegevens uit een database moet halen is dat natuurlijk (relatief) enorm traag en een verspilling van energie (CPU/memory). Het statisch opslaan van het resultaat van de pagina scheelt op veel vlakken werk en zorgt voor een veel snellere site.

Aangezien Google "om gebruikerservaring" geeft, wordt site-snelheid ook als factor meegenomen bij het bepalen van de plek in zoekresultaten.

Wanneer de site voor elke request de pagina moet opbouwen en gegevens uit een database moet halen is dat natuurlijk (relatief) enorm traag en een verspilling van energie (CPU/memory).

Wat je zegt is niet helemaal kloppend. Als de website het moet dan zul je ook met front-end caching volgens mij niks oplossen, aangezien er blijkbaar aan de achterkant zoveel verse data is dat het moet... Als de data niet zo vaak ververst wordt, dan is het alsnog een probleem voor de achterkant: daar weet je hoe vaak de data vers is en dus wanneer er een nieuwe opbouw gedaan kan/moet worden. Dat kan dan daarna alsnog met front-end caching versnelt worden zodat de opgebouwde pagina niet steeds 'van achter' hoeft te komen.

[offtopic]Ik heb echt helemaal geen verstand van websites en de huidige technieken [/offtopic]

Dat ligt helemaal aan de klant zelf. Iedereen wil voor een dubbeltje op de eerste rij. Meestal neem je een bestaande website over met dit bekende probleem. Ga jij dan maar iemand vertellen met 20 plug-ins en een oude thema. Dat je alles opnieuw moet maken en het meer gaat kosten om het sneller te maken dan dat hij voor de website heeft betaald.

Dan is caching idd de snelste lapmiddel

Hangt er natuurlijk puur af wat met de website wilt doen en wat ie eisen zijn.

Dit komt vaak doordat de plugins niet al te up-to-date zijn of slordige code gebruiken. Een caching plugin gebruiken en Gzip aanzetten (in .htaccess) wil nogal eens helpen. Niet eenvoudig : Je kunt ook je site analyseren op gtmetrix.com en kijken of bijvoorbeeld plaatjes geoptimaliseerd worden. Die site biedt vaak daar kant en klaar te downloaden alternatieven voor (i.e. een rescale van een plaatje)

Ik herken dat wel. Momenteel probeer ik te leren hoe een website in elkaar te zetten met Joomla, maar vind het als non-expert vrij lastig om overal rekening mee te houden.

Wellicht toch maar eens kijken naar Wordpress voor mijn website dan als dat zoveel simpeler is. Gebruik eigenlijk alleen Joomla omdat degene die mijn website bouwde daarvoor koos. Nu ik het zelf wil bijhouden vind ik het echter lastig.

Joomla kan echt niet meer hoor in 2018

WordPress wel dan?

want?

Waar loop je dan precies tegenaan? Ik ben wel iets bekend in Joomla.

Het is misschien makkelijker te leren als je zelf een Joomla site in elkaar frutselt, een kopie van je huidige site maar dan thuis lokaal oid.

Kan vaak wat makkelijker zijn om zelf van scratch te beginnen dan verder te bouwen op andermans werk. Vooral met programeerachtig werk is het werken op andermans spul soms erg lastig (vaak simpeler om dingen te vervangen dan te fixen)

Heeft iemand wel eens nagedacht over hoe je technisch & security-wise het beste wordpress kunt draaien? Dus met in acht neming van het feit dat WP in principe op ieder moment gapende security gaten kan hebben, en kwaadwillenden scripts zouden kunnen plaatsen, en dan verder kunnen gaan etteren.

Dus Apache of Nginx met FPM, maar dan de rechten van de files? Met FPM is het verleidelijk om PHP met dezelfde rechten als de (s)FTP(s) user te laten draaien, maar dat betekent ook dat overal in de documentroot PHP files kan (her)schrijven.

Mij leek het in principe altijd het beste om alle PHP bestanden onschrijfbaar te houden voor de webserver. Daar waar WP moet kunnen schrijven voor posts/media (wp-content/uploads) zou je iig. PHP processing uit moeten schakelen, en de rest (updates van WP, installeren van plugins etc) zou WP naar zichzelf moeten FTP-en, waarbij je uiteraard credentials niet opslaat. Dat laatste is dus wel altijd een handjob en niet erg fijn werkbaar voor de gemiddelde user die alles zo makkelijk mogelijk wil hebben.

Alles moet wel altijd door de 'user' te besturen/bewerken zijn, en deze user heeft geen SSH toegang en dus ook geen root rechten.

Ik ben benieuwd naar verdere ideeen hierover

De rechten op een bestandssysteem zijn pas een probleem als men daadwerkelijk binnen is gekomen.
Desalniettemin goed dat je rekening houdt met permissions, echter als men binnen is op je server heb je een groter probleem.

Verder moeten PHP-scripts gewoon geen user-input vertrouwen. Dan mag de PHP-user wat mij betreft alles kunnen aanpassen op het bestandssysteem binnen zijn eigen user/group.

Kortom: als het lek is, heb je sowieso een probleem en zou ik er niet op vertrouwen dat de permissies je gaan redden.

De rechten op een bestandssysteem zijn pas een probleem als men daadwerkelijk binnen is gekomen.
Desalniettemin goed dat je rekening houdt met permissions, echter als men binnen is op je server heb je een groter probleem.

De permissies zijn wél een probleem. Als WordPress schrijfrechten op zijn eigen code heeft betekent dat dat een bug in WordPress kan leiden dat de code van WordPress aangepast wordt, waardoor de server arbritaire code gaat draaien. Daarmee kom je dus binnen. Het is dan ook een heel slecht idee om een (web)applicatie schrijfrechten op zijn eigen code te geven.

Ja, en daarom was mijn stelling ook: je gaat er vanuit dat het hackable is. Hoe host je dat dan, om dat zo moeilijk mogelijk te maken (onmogelijk is het nooit, maar je kunt het wel erg moeilijk maken ..)

Vrij simpel.

Als eerst op serverniveau fail2ban. Ngix is goed in verhouding met apache. Als wordpress aangevallen wordt dan crashed je apache niet. Ngix heeft in theorie veel meer resources. Second; stel een cron in (dagelijks, 05:00) met Maldet (unix) > die kan je mooi waarschuwen als je site toevallig malware heeft.

Dan lokaal: verwijder als eerst alles wat je NIET gebruikt. Wordpress komt standaard met 3 thema's mee. Flikker die eruit als je ze niet gebruikt. Thema's zijn vaak lek. Wordfence is een goede security plugin maar helaas, sinds dat ze meer en meer betaald willen zien zijn de functies veel kleiner geworden voor de gratis versie.

Standaard wp-login.php en WP-admin beveiligen met een htaccess; handig voor jezelf en klant. Stopt bruteforce aanvallen.

Vervelende aan WordPress is dat klanten met Woocommerce wp-login nodig hebben voor hun bestellingen. Wat dat betreft is het jammer dat het admin deel niet zijn eigen login file heeft (zoals bij veel andere cms systemen).

Je kunt ook de login pagina hernoemen naar /inloggen met een plugin als:
https://nl.wordpress.org/plugins/wps-hide-login/

WP is prima op een professioneel niveau te gebruiken, het opzetten van een otap e.d. is prima te doen met WP. We zetten het bij pure content websites vaak in als headless CMS omdat het voor de klant fijn/bekend werken is, terwijl we aan de frontend maatwerk leveren (hoeft geen php te zijn). Die twee kunnen volledig gescheiden werken, qua domein en beveiliging. Afbeeldingen slaan we vaak extern op (S3 bijvoorbeeld), waardoor scaling van webservers ook geen issue hoeft te zijn (naast andere caching-oplossingen).
Plugins zijn vaak beperkt tot eigen gemaakte (Elasticsearch implementatie oid), waardoor je veel update issues al voorkomt.
Het grootste nadeel is dat WP kan ombouwen tot een oplossing voor de meeste problemen, terwijl het daarvoor echt niet de meest geschikte tool is. 'use the right tool for the right job' principe zeg maar

Afgezien van de tips die al gegeven zijn en het updaten van je plugins kun je WordFence gebruiken, die houdt heel veel crap (aanvallen) buiten de deur.

Benieuwd hoe lang deze trend doorzet. Persoonlijk ben ik steeds meer geïnteresseerd in het concept van static cms. Recentelijk voor enkele klanten website opgezet met Hugo (https://gohugo.io/). Werkt echt super en samenwerken met andere developers is ook stukken fijner.

Alles heerlijk in git, eenvoudig om automatische build e.d. op te zetten. Voor de mensen die geïnteresseerd zijn in hugo, kijk dan ook eens naar Netlify. (https://www.netlify.com/)

Voor developers is dat lekker ja. Maar voor niet-technische mensen die een website willen bijwerken lijkt het me niet dat ze heel blij worden van markdown schrijven en pushen naar een git repository. Voor wat voor soort klanten heb je dat opgezet?

Geschikt voor bedrijven met bijvoorbeeld een eigen marketing afdeling. Meeste marketing afdelingen zijn wel redelijk onderlegd met bijvoorbeeld html/markdown. En basic git workflow heb je ook wel in een ochtend uitgelegd.

Voor organisaties waar wat minder technische kennis in huis is kan je prima uit te voeten met bijvoorbeeld een dienst zoals: https://forestry.io/

Je workflow werkt dan als volgt:

Forestry -> commit > git repo -> git hook -> netlify -> deploy

Een static cms heeft enorm veel voordelen, alleen ben met je eens dat het niet geschikt is voor iedereen.

Tja, ik heb twee jaar lang serieus geprobeerd klanten te (laten) migreren van WordPress naar Kirby ( flat-file / no-db CMS https://getkirby.com/ ).

Maar (bijna) geen enkele klant wilde er aan... op een handjevol na in die periode van twee jaar.

Toen ben ik gaan testen wat nu sneller werkte, qua development en performance;

Exact dezelfde site gemaakt ( qua content, html-code ) alleen dus andere back-end / php-code.

In de praktijk scoorde WP marginaal sneller dan Kirby ( +/- 5% ) zonder caching en ongeveer hetzelfde met caching.

Tel daarbij op dat Kirby qua CMS een drama is voor klanten ( alles markdown, geen (goede) user-management, assets gebonden aan een pagina ( geen centrale asset library ), etc... etc... dus uiteindelijk ben ik weer volledig terug bij WP.

Als je WP gebruikt waar het voor bedoelt is ( CMS ) en de rest van je ( SPA functions ) gewoon in native PHP code, zonder al die vage hooks en actions, is het gewoon een snel, stabiel en robuust systeem ( en backwards compatible tot meer dan vijf jaar - waar Kirby bv. bij elke major update alle oude versies 'broken' maakte )...

Het feit dat een flat-file databaseloze site niet langzamer is dan Wordpress, zegt denk ik meer over de snelheid van Wordpress dan Kirby

Snelheid is voor mij niet de enige reden. Veiligheid is ook belangrijke keuze om steeds vaker te kiezen voor een static cms. Een platte html structuur is nu eenmaal stuk lastiger te hacken dan een server met een database erachter.

An sich is systeem zoals WordPress veilig, mits je alle updates goed bijhoud. Je kan kiezen om automatisch plugin updates uit te voeren. Nadeel hiervan is weer dat je geen goed overzicht hebt wanneer iets kapot gaat op je website na aanleiding van een plugin update.

Voor een aantal klanten met WordPress websites hebben we dan ook een onderhoudscontract afgesloten. Waarbij plugin updates x aantal keer per maand bijgewerkt, getest en gepubliceerd worden.

[ .. ]
An sich is systeem zoals WordPress veilig, mits je alle updates goed bijhoud.
[ .. ]

Nou .. nee. Dat is per definitie al nooit waar (niets is 100% veilig, hooguit veiliger als je updates (automatisch) bijhoudt). Maar daarnaast bieden behaalde resultaten uit het verleden je praktisch wel garantie dat er in zowat iedere versie van WP wel behoorlijke lekken zitten. Niet om de boel af te kraken, maar zo is het gewoon gebleken. En dan heb je het daar nog maar over de dingen die bekend zijn. Reken maar dat serieuze hackers een enorme bak aan 0day hacks en exploits op de plank hebben liggen voor WP en allerhande plugins/themes van WP.

Eens, voor veel websites meer dan voldoende. Kijk ook eens naar: https://jekyllrb.com/

ideaal systeem, zeker wanneer je plugin vrij houdt (daar zit vaak het veiligheidsrisico) binnen 10min. werkende site met standaard CMS.

Zolang er geen gevoelige data op de website staat is het gebruik van plugins prima. Wel altijd goed opletten hoe up-to-date de plugin is.

Nee, want je site kan ook als e-mailplatform misbruikt worden, bijvoorbeeld.
Als jouw server 1000en mailtjes verstuurt kan je je e-mail reputatiescore wel gedag zeggen.

Verder kan een plugin natuurlijk zelf kwetsbare code uitvoeren die wat dan ook doet, dit is slechts een voorbeeld; het sturen van e-mail via een script dat ze zelf "geüpload" hebben.

Vulnerable zijn is dus wel altijd fout, ook als je geen gevoelige gegevens op je website hebt staan; je wil niet dat je site ineens down is, of je server misbruikt wordt.

[Reactie gewijzigd door twicejr op 5 maart 2018 15:39]

Nee, want je site kan ook als e-mailplatform misbruikt worden, bijvoorbeeld.
Als jouw server 1000en mailtjes verstuurt kan je je e-mail reputatiescore wel gedag zeggen.

Wellicht je webserver niet als mailserver gebruiken en je webserver niet in je SPF zetten?

Hoe wil je dan mailen vanuit Wordpress?
Die gebruikte instellingen kunnen toch misbruikt worden, maakt dus niet echt uit waar je mailserver draait.

SMTP i.c.m. Google Apps of Zoho?

Het probleem is dat de aanvaller de Wordpress mailfuncties zal gebruiken als hij binnen is..
of dat SMTP via Google Apps werkt maakt voor de aanvaller niet uit.

[Reactie gewijzigd door twicejr op 5 maart 2018 17:11]

Klopt. Maar je zit niet met je reputatiescore.

Mijn ervaring leert mij dat sites die “gehacked” worden, niet worden ge-updatet en/of niet zijn voorzien van strenge wachtwoordregels.

Dit is dan gelijk een probleem bij praktisch elk cms. Zelfs in heb super-veilige Pimcore worden regelmatig exploits gevonden.

Zelf beperk ik het aantal plugins tot de grote populairdere plugins die onderhouden worden door grotere bedrijven, zoals bv. Yoast SEO.

Plugins is altijd een issue met CMSen. Maar een hoop goede plugins voor Wordpress worden ook heel netjes bijgehouden en kunnen heel gemakkelijk geupdate worden.

Je vergeet themes/templates, die kunnen ook de boel vernagelen bij major releases (een aantal major releases geleden meegemaakt bij Wordpress).

Het nadeel van het zo simpel maken is dat iedereen denkt het te kunnen installeren, maar vaak vergeet men dan het veilig te doen en zorgt uiteindelijk nog voor problemen...

Wordpress werkt qua interface mooi. Iedereen kan ermee werken. Maar de onderliggende code is werkelijk verschrikkelijk. Ik zou het niet op mijn server durven draaien. Ik heb het zelf meerdere malen gebruikt: als voorbeeld van hoe je *niet* niet programmeren bij interne curssusen over secure webdevelopment. En ik hoor nu de mensen al roepen: het zijn vooral de plugins die onveilig zijn. Dat zal best, maar Wordpress biedt te weinig mogelijkheden om veilige plugins af te kunnen dwingen. Het is heel makkelijk in Wordpress om het fout te doen.

De WordPress code is inderdaad een chaotische brei.
Dat verbaasd me nogal, aangezien het behoorlijk stabiel is.

Aangezien het op zo'n groot aantal sites en servers draait komen problemen ook snel aan het ligt en kan het verholpen worden.

Wat heeft spaghetti code met stabiliteit te maken?

Leesbaarheid en complexiteit maken het niet eenvoudiger om functionaliteit toe te voegen of te onderhouden, het helpt dus niet mee.

Daarnaast is het lastiger te onderhouden, testen, etc.

Ik vraag me af wat het percentage wordpress sites is bij de top één miljoen populairste websites.

Want laten we nu even eerlijk zijn;
Hoe populair kan website nummer 1.000.001 tot en met 10.000.000 nu werkelijk zijn?
In welke grootorde bevindt zulke website zich?

Ik heb een website op plek 1.700.000, zit rond de 200K pageviews per maand tegenwoordig. Zat een paar jaar geleden bij de bovenste 1.000.000 en toen schommelde het tussen 500K en een miljoen. Overigens op een zelfgemaakt CMS/community systeem.

Zijn nog steeds grote websites. Er zijn een paar miljard sites, dus de eerste 10 miljoen zijn nog steeds <1% populairste sites. Alexa rankt ze tot zo'n 30 miljoen lijkt het.

[Reactie gewijzigd door BarôZZa op 5 maart 2018 16:03]

Wij “bouwen” veel op Wordpress.
Klant kan er goed mee overweg. Genoeg goede plug-ins te krijgen/te koop mocht dat nodig zijn én anno 2018 lijken veel bedrijven geen €5.000+ meer te willen investeren in een website. Té veel “zolderkamer” studenten die voor €500,- complete websites opleveren. Wordpress is dan mijn insziens één van de betere alternatieven. Ook WooCommerce is behoorlijk volwassen geworden. Wij hebben meerdere klanten die zo’n 500K plus per jaar doet in een Woocommerce site en daar super tevreden mee zijn.

ManageWP om de sites van updates te voorzien.

Een grote zwakke schakel, klanten en hun té simpele wachtwoorden, hebben we ook uitgeschakeld. Toch nog wel eens gezien dat een klant “admin:admin” een verstandige login is.

Ik vind dat gewoon gevaarlijk, woocommerce op een wordpress omgeving. En zeker als er 500k op jaar aan omzet mee wordt gedaan.

Wat denk je dat er voor het oprapen ligt zodra je site met een last minute exploit lek raakt? Wat denk je dat er gebeurd als een hacker de het te ontvangen adres van je payment api wijzigt? Of wat denk je dat de schade zal zijn als er andere rotzooi op wordt geplaatst?

Ik heb klanten die adult bieden op basis van woocommerce. Ik raadt het eigenlijk altijd af om de bovenstaande redenen. Ik had ook een andere klant die persooneelsleden in o.a plain text in de database opsloeg. Dit om in 1 oogopslag dames aan / af te kunnen melden. Ik wist niet wat ik zag.

Dit soort dingen sla je gewoon niet op in een website. Ook zoiets. Contactformulier in wordpress met file upload mogelijkheid. Harstikke prima. Echter bij wordpress wordt er altijd een kopie van zo'n bestand achtergelaten.

Ik doe het in m'n eigen maatwerk geheel anders. Zelfde formulier met upload mogelijkheid > mailen en weggooien. Geen verwijzing ergens in een map met /uploads ofzo. Gewoon zoals het hoort.

Een hele hoop “wat als”. Je kunt een hele hoop afvangen. Een hacker zal hier niet zo snel een API koppeling wijzigen. Binnen no-time heb je dit door en het is direct terug te leiden. Je kunt niet als zomaar iemand een mollie account, laat staan een Internetkassa account aanvragen.
Plus je hebt een hele fijne plug-in voor wordpress die bijhoudt of bestanden gewijzigd worden. Per mail krijg je direct een melding als er via bijv een injection nieuwe bestanden worden geplaatst.

Daarbij ben je ook bij een eigen cms niet 100% zeker van de veiligheid. Maar ik begrijp je wel, echter denk ik dat als je de boel op orde hebt, met welk cms dan ook, de kans op een veiligheidssituatie minimaal is.

Plus je hebt altijd de factor:klant
Wat bereken je de klant voor een webshop op een custom cms, custom ontwerp en in veel gevallen een hoop custom werk en de ondersteuning. 20.000+? Onze klanten kijken dan graag even verder.

Ps. als jij dit doet voor heel veel minder dan moeten we wat uitgebreider contact hebben.

Mollie PayPal vind ik altijd een beetje dubbelzinnig . Maar goed als iemand binnen is dan kun je natuurlijk in dat geval ook alleen die mollie PayPal betaalmethode uitschakelen en vervangen voor de standaard PayPal implementatie naar een ander PayPal adres. Dan merkt jouw klant dit pas wanneer hij zijn tegoed gaat controleren. Zeker wanneer de andere methoden normaal doorlopen. Dus daar heeft Jism toch wel een puntje lijkt me. Niet dat het met een ander systeem gegarandeerd wel goed gaat, daar heb jij dan weer gelijk in.

Ja en nee. In het huidige geval krijgt de webshop eigenaar ern mail met “nieuwe bestelling voor klant xxx” en gelijk van mollie of welke provider “betaling ontvangen”/ uiteraard blijf je het altijd houden. Maar goed,
Werken met ip whitelist voor admin, dubbele authenticatie en de boel in de gaten houden en je bent een heel eind.

Met een Woocommerce website loopt je klanten account ook via wp-login. Wat heb jij voor oplossing voor admin whitelisting om daar omheen te werken?

IP voor de admins. Users uitsluitend via frontend login. Volgens mij omzeil je daarmee altijd de backend.
Sowieso Sucuri installeren en ik blijf er dan bij dat je echt wel een goed (nooit perfect) beveiligde site hebt.

Altijd drama om de home made sites te zien - als ze er zelf niet meer uitkomen. 3 pagina's plugins, ieder admin-scherm gevuld met waarschuwingen en reclame voor betaalde versies, en alles zo traag als een slak. (Wat je weer kunt oplossen met 2 á 3 cache plugins. Meer is beter tenslotte.)

Ik gebruik het nog wel eens maar probeer WordPress te vermijden. En de klanten die menen dat WordPress het beste en enige cms is.

Gek he, kunnen ze ook bepalen aan hand van die gegevens wat voor type websites het zijn?
Wordpress is een Blogging cms en zonder plugins is met meerdere mensen erop werken een grote uitdaging. Joomla is van huis uit, beter geschikt om o.a. via de administratieve achterkant een simpele ledenadministratie te onderhouden. zonder extra plugin.
MODX, zie ik trouwens niet eens op het lijstje staan.

Logisch ook als het gaat om instalaltie. Vaak kan dat de huis-tuin-keuken gebruiker ook wel.
Zelds 1-installers bieden veel hosters aan. Wat het helemaal makkelijk maakt.