WordPress rolt geforceerd update uit tegen kwetsbaarheid in UpdraftPlus-plug-in

WordPress rolt geforceerd een update uit voor de populaire back-up-plug-in UpdraftPlus. Websites met de plug-in bleken een kwetsbaarheid te bevatten waarbij onbevoegde gebruikers recente back-ups konden downloaden.

Het gaat om de verplichte UpdraftPlus-updates 1.22.3 en 2.22.3 voor respectievelijk gebruikers van de gratis en betaalde versie van de plug-in. Na installatie is het niet meer mogelijk voor onbevoegde gebruikers om toegang te krijgen tot back-ups, zo beschrijft plug-inmanager Jetpack in een blogpost.

WordPress forceert slechts zelden een update, maar vanwege de ernst van de betreffende kwetsbaarheid is de update volgens Bleeping Computer binnen enkele dagen bij 3 miljoen gebruikers geïnstalleerd. Desalniettemin zijn er volgens UpdraftPlus vanwege het ingewikkelde proces van het onbevoegd verkrijgen van een back-up zover bekend geen hacks uitgevoerd.

Door de kwetsbaarheid in UpdraftPlus konden gebruikers een heartbeat-verzoek naar een website sturen, waarna belangrijke data over recente back-ups verkregen kon worden. Op basis van deze data kon vervolgens een link gegenereerd worden. Deze link gaf UpdraftPlus de opdracht om de betreffende back-up via een e-mail naar de niet-geautoriseerde hacker te sturen.

Reacties (94)

[Stroopwafels]

Er is veel commotie in de interne WordPress Slack chats vanwege het feit dat ze geforceerd een update hebben gedaan voor deze kwetsbaarheid. Normaal doet WordPress dit alleen voor echte ernstige kwetsbaarheden, in dit geval kan dit alleen misbruikt worden met een account wat niet mogelijk is op de standaard WordPress installatie (of dit moet handmatig aangezet worden, of via een plugin zoals WooCommerce) en hierbij komt ook dat het niet op alle server environments werkt.

Iedere week heb je wel een kwetsbaarheid die veel erger is dan dit, maar daar doen ze geen geforceerde update voor omdat het minder actieve installaties heeft. Het feit dat 1 persoon een besluit als dit heeft genomen (een update forceren) vinden veel mensen niet OK, zelfs andere WordPress core bijdragers.

[Reactie gewijzigd door Stroopwafels op 24 juli 2024 15:34]

[Tinytauren]

De vraag is ook, wanneer is het “ernstig”. Ik vind eerlijk gezegd best ernstig. Ik wil niet dat kwaadwillenden backups van mij en mijn klanten kunnen downloaden zonder toestemming. Hierdoor kunnen ze toegang krijgen tot de gegevens van mij, mijn klanten en hun klanten. Oftwel, ik kan binnen een haverklap mijn deuren sluiten als ik iedereen moet gaan inlichten, dat door een WordPress plugin, die althans geweldig goed werkt… de reden is dat gegevens zijn gelekt.

Ik vindt het persoonlijk, wel een goede stap, om dit te forceren. Ik kan dit ook niet elke dag bijhouden, naast alle andere activiteiten. Blij dat iemand over mijn schouder meekijkt!

[Stroopwafels]

Of iets ernstig is zal inderdaad erg verschillen tussen de normale WordPress gebruiker, de ontwikkelaars en de security researchers. Voor de meeste security researchers zal dit niet het geval zijn. Het probleem is eerder dat ze de update wel hebben geforceerd voor deze kwetsbaarheid maar vrijwel nooit doen voor andere ergere kwetsbaarheden.

[abroes]

In onze plugin (3+ miljoen active installs) is er onlangs een zware kwetsbaarheid gevonden en een paar dagen later is de update geforceerd door het .org-team. Gebeurt toch vaker dan je denkt.

Was overigens niet de eerste, maar tweede keer voor onze plugin.

[Reactie gewijzigd door abroes op 24 juli 2024 15:34]

[jurroen]

De vraag is ook, wanneer is het “ernstig”. Ik vind eerlijk gezegd best ernstig. Ik wil niet dat kwaadwillenden backups van mij en mijn klanten kunnen downloaden zonder toestemming.

Hier wil ik graag even op inhaken; jouw opmerking doet vermoeden dat je dit commercieel / zakelijk gebruikt. In zo'n geval zou ik adviseren om een andere backupstrategie te implementeren.

Er zijn twee grote nadelen aan backup plugins, in de algene zin: standaard worden de backups meestal in de 'document root' opgeslagen. Vanuit een security perspectief wil je dit niet.

En ook: een backup plugin is afhankelijk van de werking van het CMS. WordPress in dit geval. Als dat even niet werkt of een fout bevat kan dat de werking van de backups beïnvloeden.

Idealiter maak je de backups op server niveau, op meerdere locaties, waarvan minimaal één niet toegankelijk is voor die server of webapplicatie - zodat je bij een menselijke fout (per ongeluk verwijderen), een aanval/ransomware óf mismanagement altijd nog bij de de data kunt.

[Tinytauren]

Je hebt helemaal gelijk, ik waardeer ook je input hier.

Als WordPress of bij andere back-up plug-ins maar één ding fout gaat, dan is je back-up oplossing meteen naar de ****. Ik heb jammer genoeg meegemaakt wat jij beschreven hebt. Je maakt fouten, je analyseert het probleem, je zorgt uiteindelijk voor een oplossing.

Heb er zelf ook voor gekozen om ook op server niveau te back-uppen. Want je bent ook afhankelijk van de laag daaronder, zoals Nginx, Apache of andere webservers.

Thanks voor je feedback

[siepeltjuh]

Ben hier niet heel bekend mee, maar uit dit artikel en jouw reactie haal ik niet goed wat nou precies het probleem is met deze geforceerde update. Zijn er zaken onder invloed van deze update omstreden technische of functionele wijzigingen doorgevoerd?

Als het een security update is waarbij je als gebruiker en beheerder geen impact hebt, zie ik het probleem niet. Maar gezien de reactie vermoed ik dat er wel degelijk impact is.

[Stroopwafels]

Zoals in het nieuwsbericht staat "WordPress forceert slechts zelden een update". WordPress heeft een pagina hier https://developer.wordpre...c-plugin-security-updates waar ook de condities staan. Niet alle condities waren gerespecteerd. WordPress doet dit normaal echt zelden. Zelfs niet voor kwetsbaarheden zoals dit in andere plugins.

Als ik denk aan een ernstige kwetsbaarheid, denk ik aan een unauthenticated RCE. Iets waarmee je zonder een account/login een WordPress website over kan nemen.

[Reactie gewijzigd door Stroopwafels op 24 juli 2024 15:34]

[RaJitsu]

Maar de vraag van @siepeltjuh is meer praktisch georiënteerd, denk ik. Wat is het praktische bezwaar tegen het doorvoeren van deze update, zelfs als er niet voldaan werd aan de kritische condities? Een veiligere omgeving is alleen positief zou je zeggen? Tenzij er functionaliteit geraakt wordt door deze update of andere nadelen spelen voor de gebruikers, wat is er tegen een dergelijke update?

Het enige dat ik kan bedenken is dat het misschien enen precedent voor toekomstig beleid is en er dan misschien iets doorgevoerd wordt waar gebruikers last van hebben, bijv. dat bepaalde tools niet meer werken.

[Stroopwafels]

Het probleem is eerder dat ze dit vrijwel nooit voor andere kwetsbaarheden doen, maar wel voor deze wat niet eens zonder een account misbruikt kan worden. Iedere week zijn er veel ergere kwetsbaarheden, zelfs voor plugins met meer dan 100.000 installaties, maar daar doen ze het absoluut niet voor.

WordPress heeft hun eigen beleid niet gerespecteerd, met name "Is the fix for the issue self-contained or does it add significant extra superfluous code?". De update die werd geforceerd bevatte veel meer veranderingen dan alleen een security patch. Als je kijkt naar de changelogs zie je ook dat ze een dag erna gelijk een nieuwe update hadden uitgebracht omdat sommige sites kapot gingen vanwege fatal errors in de plugin code.

Voor de gemiddelde gebruiker snap ik het wel, een geforceerde update is erg goed voor deze situaties. Maar... ze doen dit dus vrijwel nooit maar wel opeens voor deze kwetsbaarheid... doe het dan voor alle plugins met ernstige kwetsbaarheden.

[siepeltjuh]

Dat het ongebruikelijk is is op zich toch geen bezwaar?! Welk inhoudelijk probleem wordt nu precies geïntroduceerd?

[[Yellow]]

Ben het wel met Stroopwafels eens. Een update forceren terwijl dat 1) niet eens een probleem oplevert bij standaard installaties, 2) de update bevat meerdere wijzigingen behalve de security patch, 3) het is niet eens een rechtstreeks te misbruiken lek.

Dat mag op zijn minst bijzonder worden gevonden.

Er draaien toch ook wel redelijk grote sites op WP en als die door deze update ineens stuk gaan is dat toch weer een reden om de volgende keer niet meer voor WP te kiezen.

[kodak]

Een forced update is niet hetzelfde als een automatische update. Bij automatische updates kan je vooraf kiezen of je dat wil of op je eigen moment wil updaten. Het staat standaard aan, en als de ontwikkelaar een update uitbrengt kan die geïnstalleerd worden. Bij forced updates heb je via de normale werking geen keuze. De ontwikkelaar beslist wat goed voor jou is, zonder zelfs maar af te vragen of dat je als website wel uit komt, of dat de wil van de ontwikkelaar belangrijker is. En dat laatste lijkt belangrijk bij jou vraag.

Als jij bijvoorbeeld meent dat er niets fout ging is voor een ander niet hetzelfde als er is niets fout gegaan. Als iemand automatische updates uit heeft gezet dan is dat bijvoorbeeld omdat het zomaar updaten voor veel voorkomende fouten niet zomaar acceptabel is zonder er zelf controle over te hebben of die updates wel aan de eigen kwaliteitseisen voldoen. Maar als je die zelfde soort updates nu via forced updates krijgt kan je er dus niet meer vooraf op controleren. Dat het achteraf misschien niet erg bleek is dan niet zomaar relevant. De keuze om alleen heel ernstige lekken geforceerd te laten updaten maakt niet iedereen zomaar.

Het is dus niet vreemd dat er discussie is wanneer een ander geforceerde updates doet. Maar eigenlijk is dat nogal laat. Want denken dat een ander alleen maar wanneer jij het wil geforceerd updates gaat doen is gewoonlijk een beveiligingsrisico. Zonder duidelijke afspraken kan je namelijk verwachten dat iemand die forced update ooit gaat gebruiken terwijl dat niet aan je verwachting of eisen voldoet. Dat het nu misschien goed ging wil niet zeggen dat het de volgende keer goed gaat. En dan mag je er rekening mee houden dat de veroorzaker niet perse in staat is of wil opdraaien voor de schade of andere negatieve gevolgen. Dat het forced updaten goed bedoeld is is dus niet genoeg. Er zal duidelijk moeten zijn wanneer de ontwikkelaar wel of geen forced update mag doen door ook rekening te houden met waarom iemand kiest om automatische updates uit te hebben gezet. Anders kan je die optie voor automatische updates net zo goed weg doen als het de ontwikkelaars kennelijk niet zoveel kan schelen wat een ander wil.

[Reactie gewijzigd door kodak op 24 juli 2024 15:34]

[Munki]

Onze plugin met meer dan 2 miljoen installaties kon "echt met geen mogelijkheid geforceerd geüpdatet worden", terwijl er een ernstige kwetsbaarheid in zat.

Gevalletje selectief dus.

[Stroopwafels]

Automattic is "eigenaar" van WordPress en... Jetpack, het bedrijf die deze kwetsbaarheid had gevonden. Dus dat verbaast mij niet helemaal.

[abroes]

@Munki voor welke plugin werk je precies?

[CH4OS]

Wellicht is het dan een optie om het om te draaien en dat beleid te herzien.

[MrFax]

Dit brengt een beveiligingsrisico met zich mee. Wat als een website verborgen & gesloten pagina's heeft? Die kunnen allemaal gevonden worden via zo'n backup, waar misschien wel bedrijfssensitieve data op staat.

[Verwijderd]

Op een fatsoenlijke server of die bij een hostingbedrijf heb je al automatisch backups. Ik vindt dat zo'n overbodige verspilling van storage als je ook nog eens in een wordpress omgeving zelf backups gaat staan draaien.

Op mijn servers (15 stuks) draai ik 2 maal daags backups (automatisch) van iedere user account op zo'n server. Met 1 druk op de knop herstel je alles, dus DNS records tot aan databases, files, mailboxen en behorende inhoud en meer.

[Oon]

Is ook heel vreemd dat dat zomaar door één iemand besloten kan worden. Ik werk al met WordPress sinds ze net van alleen blog naar ook CMS gingen, inmiddels is het van een mooie tool uitgerold naar niet veel meer dan bloatware in een leuk jasje.
De enige reden om nog WordPress te gebruiken is de plug-ins die vaak niet zomaar voor een andere oplossing te vinden zijn, en het gebrek aan een echt goed alternatief. Als er nou een alternatief was dat net zo goed werkt als WordPress, dezelfde mogelijkheden heeft, en ook door mijn klant te gebruiken is, dan zou ik vandaag nog alle websites van mijn klanten gratis voor ze ombouwen om van dit grote veiligheidslek op mijn server af te komen.

[Sn0wblind]

Begrijp werkelijk waar niet waarom Wordpress nog anno 2022 als valide CMS wordt gezien voor middelgrote tot grote bedrijven. Het is zo log geworden, het heeft zoveel legtacy code er in zitten en de fundamentals zijn daardoor al problematisch. Het erge is dat veel developers het notabene verdedigen en eigenlijk niet willen meegroeien met de industrie (iets wat heel erg raar is als developer zijnde en de cultuur die hierachter hangt)..

[prodesk]

Veel grote websites maken er nog gebruik van, althans talloze gerenommeerde kranten.

[litebyte]

Klopt, het mediabedrijf waar ik zelf voor werk heeft minimaal 30+ websites waar het op draait, met miljoenen bezoekers per dag. Wordpress zelf is vaak ook niet het probleem. Het probleem is de (hoeveelheid) plugins die vaak worden geinstalleerd.

[Tinytauren]

Precies, ook de onderliggende lagen spelen een grote rol.

Hoe installeer je, manage en optimaliseer je de database omgeving. Welke andere you ondersteunende factoren reken je mee?

Ken veel bedrijven die vooral de focus leggen op WordPress, maar niet op de ondersteundende lagen zoals PHP8.0+, HTML versie 2 en werkgeheugen databases zoals Redis voor caching. Er komt best veel kijken bij WordPress.

[McBacon]

HTML versie 2? Bedoel je niet HTTP/2? ;]

[Tinytauren]

HTML versie 2? Bedoel je niet HTTP/2? ;]

Mijn excuses, dit was inderdaad wat ik bedoelde

[Sn0wblind]

Dat maakt het niet automatisch tot een goed product.

[Mars Warrior]

Ach, het is stabiel en met zoveel plug-ins kun je heel veel bouwen: van een soort AirBnb tot een recruiter site waar je je CV kunt uploaden enzo.

Wordpress is meer dan een CMS waar je pagina's kunt maken.

Ik ken geen alternatief CMS dat zoveel kan zonder te hoeven programmeren.

En gebruik je een professionele builder zoals Divi of Beaver Builder, dan kom je niks tekort lijkt me.

[Sn0wblind]

Divi is geen professionele builder, naast het is langzaam. Beter purpose built systemen opzetten dan die houtje touwtje plugin op plugin op plugin sistes. De UX is ook helemaal niet op elkaar afgestemd. Sorry maar dat soort builders zijn leuk voor de hobbyist.

[Tinytauren]

Als eerste vraag ik me af waarom jij bepaalde conclusies trekt, zoals “Divi is geen professionele builder … dat soort builders zijn leuk voor de hobbyist”.

Heb ook je andere reacties gelezen en deze komen volgens mij allemaal vanuit jouw persoonlijke ervaringen. WordPress is niet voor niks dit moment een van de grootste marktleiders qua CMS. Divi, Elementor en andere builders.. zijn niet voor niks de meest populaire website building tools. Het werkt, het functioneert en het doet zijn werk.

Wij gebruiken al jaren WordPress, maar de kunst ligt niet alleen bij WordPress zelf, het zijn de plugins, de manier hoe je WordPress inzet, de hardware, type database(s), de onderliggende lagen zoals PHP, HTML 2.0, CDN, Caching, memory based databases als ondersteuning.

WordPress is in mijn ogen, tegenwoordig een kunst, om echt optimaal en succesvol in te zetten. Het is een geweldige tool, met natuurlijk zijn scheuren en barsten hier en daar… maar het heeft veel mogelijk gemaakt in de wereld van webhosting van kleine tot grote bedrijven!

[Sn0wblind]

Als eerste vraag ik me af waarom jij bepaalde conclusies trekt, zoals “Divi is geen professionele builder … dat soort builders zijn leuk voor de hobbyist”.

Omdat het puur relateif simpele page builders zijn welke de nuances missen om een echt passende oplossing te bouwen.

Heb ook je andere reacties gelezen en deze komen volgens mij allemaal vanuit jouw persoonlijke ervaringen. WordPress is niet voor niks dit moment een van de grootste marktleiders qua CMS. Divi, Elementor en andere builders.. zijn niet voor niks de meest populaire website building tools. Het werkt, het functioneert en het doet zijn werk.

Ik ben lead designer en voormalig front-end developer. Heb een mooie CV met een flinke rij aan mooie bedrijven waar ik oplossingen voor heb mogen designen EN bouwen.

Wordpress is de grootste, niet marktleider, De grootst eomdat iedere hosting wel een 1 click install aanbiedt, Omdat het mensen laat denken dat zij een super mooie website hebben weten te bouwen dankzij een builder theme maar onder de motorkap zit het tjokvol issues (dan laat ik de interface nog achterwege wat zij opzetten). De hoeveelheid isntallaties zegt niks als je niet kijkt naar het gebruik hiervan. Wordpress wordt steeds minder ingezet voor commerciele producten. Waar je 5 jaar geleden nog wel een Wordpress installatie kon vinden voor echt grote sites is dit steeds minder geworden vanwege de aangehaalde redenen. De MKB zit er nog een beetje in vast want het voelt als kosten effectief aan op de korte termijn. Naast je hebt tig "website bouwers" welke een Wordpress site voor nog geen 1000 euro aanbieden en gewoon een template voor je installeren.

Wij gebruiken al jaren WordPress, maar de kunst ligt niet alleen bij WordPress zelf, het zijn de plugins, de manier hoe je WordPress inzet, de hardware, type database(s), de onderliggende lagen zoals PHP, HTML 2.0, CDN, Caching, memory based databases als ondersteuning.

Een agency met wie ik niet zou werken , even zonder dollen. .Er is een markt voor maar de markt houdt zichzelf in stand. Alles wat je bouwt is afhankelijk van hardware, database architectuur, codebase, wel of geen CDN etc. Wordpress is alleen nu wel een platform geworden wat iets doet waar het niet oorspronkelijk voor ontworpen is en al die oplossingen zij aan elkaar geplakt maar niet efficient. De interface back-end is voor content managers ook niet efficient. Het neemt geen recent geleerde conventies mee om het beter te doen.

WordPress is in mijn ogen, tegenwoordig een kunst, om echt optimaal en succesvol in te zetten. Het is een geweldige tool, met natuurlijk zijn scheuren en barsten hier en daar… maar het heeft veel mogelijk gemaakt in de wereld van webhosting van kleine tot grote bedrijven!

Maar is dit een reden om eraan vast te houden? Omdat het 10 jaar terug veel mogelijk heeft gemaakt? Het is nu 1 groot monolithic systeem. Je kan op andere platformen iets beters bouwen als je precies voor het specifieke doel gaat ontwikkelen en ontwerpen. Hogere startup kosten maar op de langere termijn gewoon goekoper naast het is gewoon vele malen sneller. De content managers vinden het dan ook nog eens prettiger werken in de praktijk. Waarom vasthouden aan iets waar nu betere oplossingen voor zijn? Het vereist nieuwe technieken leren ja, nieuwe architecturen etc. Maar dat is deze sector. Constante vooruitgang en het web beter maken.

Het erge is, het zijn juist agencies die er aan vast blijven houden die ervoor zorgen dat wat ik hierboven noem niet begrepen wordt door klanten. Voor mijn freelance werk wat ik naast mijn vaste job doe bouw ik soms een platform voor meer niche klanten. Ik geef ze letterlijk de oplossing, een mooi headless CMS solution draaiende op SanityCMS+GatsbyJS, super snel, lean, minimum maintenance versus een Wordpress oplossing voor hetzelfde bedrag. Ze neigen sneller naar Wordpress puur omdat ze de naam kennen ongeacht dat eht onderhoud traject veel problematischer is.

[litebyte]

Het erge is, het zijn juist agencies die er aan vast blijven houden die ervoor zorgen dat wat ik hierboven noem niet begrepen wordt door klanten.

Gaat u zeggen dat (lead)developers bij het mediabedrijf waar ik voor werk (met letterlijk vele tientallen websites draaiend op Wordpress, met miljoenen bezoekers per dag) een totaal verkeerd besluit hebben genomen om bewust voor Wordpress te blijven kiezen en te gebruiken?

Heeft u enig idee waarom Wordpres zo populair is en waarom het zoveel gebruikt wordt?

Ze neigen sneller naar Wordpress puur omdat ze de naam kennen ongeacht dat eht onderhoud traject veel problematischer is.

[Sn0wblind]

Ga je nu zeggen dat (lead)developers bij het mediabedrijf waar ik voor werk (met letterlijk vele tientallen websites draaiend op Wordpress, met miljoenen bezoekers per dag) een totaal verkeerd besluit hebben genomen om bewust voor Wordpress te blijven kiezen en te gebruiken?

Ik zeg dat er betere oplossingen zijn als lead designer welke award winning ecom platformen heeft ontworpen en een CMS architectuur & interface heeft ontworpen.

Heeft u enig idee waarom Wordpres zo populair is en waarom het zoveel gebruikt wordt?

Waarom blijven mensen alle gebruikers onder 1 noemer scharen? Er zijn miljoenen hobbyisten die de 1click wordpress installatie gebruiken van hun hosting platform, miljoenen bloggers etc. Niet elke Wordpress gebruiker is hetzelfde. In het moderne commerciele landschap. Laten we zeggen de laag boven het MKB is Wordpress helemaal niet zo populair meer om goede redenen.

[Verwijderd]

Ik heb een speciale server, voor puur wordpress installaties, en dat is primair om de performance te waarborgen. Ik gebruik hier litespeed enterprise voor en redis object cache. Normaal gezien op een kale Apache server met PHP 7.4 zou ik in theorie 150 wordpress sites tegelijk kunnen draaien en de load op een rustige 2% te kunnen houden. Ook als het druk is. Met litespeed en redis object cache kan ik op dezelfde machine, ruim 400 wordpress websites hanteren, waar de load ook 2% is.

Het is schandalig dat het draaien van wordpress een aparte configuratie nodig heeft en zoveel mogelijk moet worden ingezet op caching omdat het anders voor geen meter draait. De kosten stijgen gewoon aanzienlijk als je als media bedrijf, courant of MKB'er alles op wordpress gaat staan baseren.

Van mij mocht het anders.

[Oon]

Divi is wel een professionele site builder optie.

Alleen een web developer gaat hier natuurlijk zelf niet mee aan de slag voor een maatwerk website, maar dat is ook niet de doelgroep. De doelgroep is marketing mensen die de website willen beheren en net iets meer nodig hebben dan Gutenberg zelf kan bieden, of MKB eigenaren die toch net iets meer willen dan Squarespace of Wix kan maar zelf niet de kennis in huis hebben.

Een professioneel resultaat krijg je er niet van, maar dat wil niet zeggen dat het geen professionele site builder is. Het spreekt gewoon een hele andere markt aan.

[Sn0wblind]

Als design lead zou ik er ook nooit mee aan de slag gaan want het is gewoon niet toereikend voor een website anno 2021. Het is leuk voor de hobbyist. Maar het is naast vaak zeg maar net niet (Want er is geen one size fits all dus maakt alles extreem generic) ook relatief langzaam door hoe de plugin zijn werk doet. Helemaal als er multilingual functionaliteit bij komt kijken door middel van bijvoorbeeld WPML. Uiteindelijk zijn voor zaken als SEO site performance enorm belangrijk. Goodluck om daarmee een degelijke score te halen.

Kaal kan Divi overigens wel prima scores halen zolang het maar op een flinke server draait, maar in combinatie met andee zaken gaat het heel hard achteruit. Wat wel ironisch is. Want hun eigen website is best mooi in elkaar gezet.

Beetje voor de types die ook vaak impressed zijn op voorbeelden van interfaces op sites als Dribbble welke bar weinig raakvlak hebben met de realiteit.

[Reactie gewijzigd door Sn0wblind op 24 juli 2024 15:34]

[Oon]

Ik wil niet op de man spelen maar ik vind wel dat je een heel bekrompen blik op WordPress hebt dan.
Bij mijn vorige werkgever hadden we een aantal hele grote klanten waar gewoon 10-20 man tegelijkertijd aan hun kan in WordPress aan het werk waren, en die gebruikten ook bijna allemaal Divi omdat het op dat moment de populairste was. Wij raadden dat natuurlijk wel af, maar uiteindelijk is het een geval van klant is koning, en als de klant al ervaring heeft met een specifieke plugin en daar expliciet om vraagt dan hebben ze over ieder alternatief dat je biedt wel wat te zeuren.

We hebben flink wat werk moeten doen om performance hoog te houden. Front-end kun je gewoon een full-page static cache inzetten, maar voor ingelogde gebruikers is dat lastiger. Zeker zoals jij zegt met plugins die gewoon slecht geschreven zijn zoals WPML of Yoast, maar dan ook meteen weer plugins zijn waar de marketingafdeling van zo'n bedrijf om vraagt omdat ze daar ervaring mee hebben.

Veel problemen hebben wij opgelost door echt alleen de minimale vereiste functionaliteit in stand te houden en flink wat eigen tussenlagen met efficiënte caching in te bouwen, en daarmee was Divi in het eindresultaat maar een hele lage drempel in het geheel.

[Sn0wblind]

Ik wil niet op de man spelen maar ik vind wel dat je een heel bekrompen blik op WordPress hebt dan.

Dat mag je utieraard vinden, no offense taken!

Bij mijn vorige werkgever hadden we een aantal hele grote klanten waar gewoon 10-20 man tegelijkertijd aan hun kan in WordPress aan het werk waren, en die gebruikten ook bijna allemaal Divi omdat het op dat moment de populairste was. Wij raadden dat natuurlijk wel af, maar uiteindelijk is het een geval van klant is koning, en als de klant al ervaring heeft met een specifieke plugin en daar expliciet om vraagt dan hebben ze over ieder alternatief dat je biedt wel wat te zeuren.

Ik weet niet bij welke agency je zat, maar de agencies waar ik heb gezeten en nu zit vinden wij Wordpress ech tniet meer van deze tijd. Wij kunnen sneller projecten deliveren met betere performance in minder tijd. Puur omdat wij niet om de problemen van Wordpress cosntant hoeven te werken. Vrijwel alels wat wij uitrollen is multilingual in deze tijd en vooral daar gaat het met Wordpress opeens heel snel heel erg mis, gewoon puur omdat het ontzettend langzaam wordt tenzij je er meer resources tegen aan gaat gooien dan je zou verwachten.

Ik vind het sowieso enigzins raar dat je als agency zijnde Divi zou uitrollen en ze eigenlijk de kans geeft om hele layout te slopen. Destijds deze wij het management met Advanced custom fields en een custom builder om ze net genoeg customization te geven maar niet teveel zodat ze eigenlijk het hele design slopen.

We hebben flink wat werk moeten doen om performance hoog te houden. Front-end kun je gewoon een full-page static cache inzetten, maar voor ingelogde gebruikers is dat lastiger. Zeker zoals jij zegt met plugins die gewoon slecht geschreven zijn zoals WPML of Yoast, maar dan ook meteen weer plugins zijn waar de marketingafdeling van zo'n bedrijf om vraagt omdat ze daar ervaring mee hebben.

Maar hierbij bevestig je ook wel enigzins mijn insteek. Je kan inderdaad met statics gaan werken, maar hoe wil je dat gaan aanpakken zodra ze ecommerce functionaliteit vragen? Of wanneer er user input benodigd is?

Veel problemen hebben wij opgelost door echt alleen de minimale vereiste functionaliteit in stand te houden en flink wat eigen tussenlagen met efficiënte caching in te bouwen, en daarmee was Divi in het eindresultaat maar een hele lage drempel in het geheel.

Het probleem met Divi is, is dat het een enigzins beperkte speeltuin is, er zijn best veel randvoorwaarden waarbij je toch vooral op het gebied van design gaat struikelen. Ook omdat het niet goed om kan gaan ngo met meer moderne standaarden. Alles in rem's/em's en koppel het aan de viewport bijvoorbeeld versus een status container size met een paar breakpoints voor responsiveness.

[Oon]

Het bedrijf waar ik werkte richtte zich niet zozeer op de klanten die een website willen, maar meer klanten die een platform willen. Dus grote nieuwsbrieven die een multisite hadden met 20 domeinen die allemaal door dezelfde personen beheerd werden, waarbij het kunnen aanpassen van de lay-out en zelfs een uniek template voor sommige artikelen gewoon een eis was.
Divi was zelfs daarbij niet mijn keuze geweest, zeker niet nadat Gutenberg uit kwam, maarja als een klant 500k neertelt voor een platform met hele specifieke specs ga je advies geven maar is uiteindelijk de keuze aan de klant.

Veel problemen werden inderdaad uiteindelijk een kwestie van meer resources, want zelfs met onze tussenlagen die zeer efficiënt waren bleven WPML en Yoast grote steekpunten. Van die plugins die alles hooken om dan weer een losse database call te doen zijn gewoon rotzooi. Dan vind ik een page/template builder nog niet zo erg, die kun je gewoon als enkel blok cachen.

Wat ik wel erg vind is dat bijvoorbeeld ook een willekeurige website van een kleine klant die ik in 2013 gebouwd heb op WordPress nog staat, maar inmiddels zoveel trager is dat ik nu bijna over moet op een ander platform. Trekt een CPU core helemaal leeg met zo'n 40MB geheugen voor een enkele pageview, zelfs wanneer ik alle plugins uitschakel. WordPress uit 2013 is wel nog van deze tijd (minus het gebrek aan security), maar de huidige WordPress is gewoon veel te veel bloat, zelfs al out of the box.

[Sn0wblind]

Voor platforms zie ik dus nog minder use cases in het huidige landschap voor Wordpress mede gewoon vanwege de security, Voor dat soort zaken gaan we standaard headless. Zo min mogelijk monolithic. Het nadeel is ook dat onze developers er ook geen trek in hebben om in hun woorden "digitale baggage" nog te tillen voor SLA werkzaamheden. Naast dat het Wordpress gebeuren technisch al issues heeft kijken developers die het moeten maintainen er nog meer tegen op. We hebben dat vraagstuk wel in het sales proces weten op te lossen. Daar zijn gewoon designers en developers bij ebtrokken en doo rmiddel van workshops met de klant vooraf ze uberhaupt getekend hebben voor een project weten we de klanten wel naar ons hand te zetten.

Wat ik wel erg vind is dat bijvoorbeeld ook een willekeurige website van een kleine klant die ik in 2013 gebouwd heb op WordPress nog staat, maar inmiddels zoveel trager is dat ik nu bijna over moet op een ander platform. Trekt een CPU core helemaal leeg met zo'n 40MB geheugen voor een enkele pageview, zelfs wanneer ik alle plugins uitschakel. WordPress uit 2013 is wel nog van deze tijd (minus het gebrek aan security), maar de huidige WordPress is gewoon veel te veel bloat, zelfs al out of the box.

Draaiden die zonder maintenance? Want het meeste wat niet meer is bijgehouden is in mijn cirkels uiteindelijk gewoon een keer gedefaced geweest en draait er opeens een Chinese spyware site op en soortgelijke rotzooi.

[Oon]

Helaas was de organisatie waar ik voor werkte niet zo van het innovatieve, zeker niet binnen development. De CEO en CTO zaten zelf ook bij de sales gesprekken voor die grotere klanten en gaven daar hun eigen input, wat het eindresultaat niet ten goede kwam.

Vwb die kleine klant van mijzelf, die website heeft nu bijna 10 jaar zonder problemen gedraaid met minimale maintenance. Zo nu en dan een keer een pagina aangepast door de klant zelf (vandaar ook dat toen WordPress een goede keuze was) en de automatische minor updates die vanuit een cronjob draaide plus een keer of 3 door de jaren heen wat grotere versie updates. Alleen inmiddels een database die 10x zo groot is en alles flink wat trager, maar ik heb toen al meteen alles zo goed het kon dichtgetimmerd en de PHP-code niet in de webroot enzo, dus nooit gehackt. Anders was het al veel eerder een nieuwe website geworden, dus misschien tijd om eens wat Chinezen uit te nodigen

[Reactie gewijzigd door Oon op 24 juli 2024 15:34]

[MiesvanderLippe]

Beslissingen worden niet genomen op basis van pure techniek. Het moet werken, begrijpelijk zijn, onderhoudbaar blijven. Het is logisch om iets te kiezen waar zo enorm veel mensen kennis van hebben en waar zo ongelooflijk veel out-of-the-box oplossingen in beschikbaar zijn.

Overigens biedt Wordpress natuurlijk gewoon prima functionaliteit voor beveiliging maar met het uitvoeren van andermans code is natuurlijk altijd een risico. Ook met je bleeding-edge NodeJS framework loop je gewoon het risico dat er een of andere isNotEqual dependency in zit met een kwetsbaarheid of backdoor.

[Sn0wblind]

Wordpress is ook qua UI niet meer van deze tijd en zeer fout gevoelig voor nog tech people. Het enige bestaansrecht naar mijn mening is echt puur legacy.

[beeldbuijs]

Ik vind dat grappig, omdat het sowieso jaren en jaren duurt voordat een systeem als WordPress zo uitontwikkeld kan worden, zoveel gebruikers kan verzamelen en er zoveel plug-ins etc voor gemaakt worden. Dus ja, niet meer dan logisch dat het oudere code bevat etc.

Welk alternatief systeem met dezelfde opties is beter volgens jou? Dat bestaat niet en als het zou bestaan, zou het precies dezelfde 'problemen bevatten.

[Sn0wblind]

De gebruikers kan je uiteraard wel opdelen in bepaalde groepen waarvan het overgrote gedeelte geen betekenis heeft, een hoop DIY website "bouwers" werlke ermee rommelen, bloggers etc.

Laat ik het even anders formuleren. Wordpress is een tool, in dit geval een hamer, en deze hamer gebruik je voor alles. Gat in de muur nodig? Pak de hamer, valkkere vloer nodig? Pak de hamer! Terwijl bijvoorbeeld een boormachine een betere tool is om een gat in de muur te maken, maar het is ook alleen maar goed daarin.

Als je een project binnen krijgt moet er eerst gekeken worden wat de scope is, requirements etc en daarop ga je de tools selecteren. Groot ecommerce platform dat actief is in meerdere landen voor een merk als Nike? Shopify plus voor ecommerce functionaliteit + Storyblok voor de content eromheen. Een lean branding website nodig? GatsbyJS+SanityCMS. Wil je een no code oplossing? Pak dan Webflow erbij etc. Je kiest de beste tools voor de usecase. Niet altijd maar diezelfde hamer. Er is geen one size fits all oplossing. Wordpress is dat ook niet, wel op papier maar uiteindelijk duurder, onveiliger, minder snel en minder prettig in gebruik voor de mensen die er content in moeten knallen.

Je haalde onderhoudbaar aan, Wordpress vereist enorm veel onderhoud omdat het onderhand een uit de kluiten gegroeide oplossingen is met zeer veel baggage.

[brobro]

Er is gewoon weinig concurrentie. Een platform met zoveel ondersteuning, zoveel plugins en mogelijkheden, zo makkelijk om mee te ontwikkelen. Het is vooral niet hip voor ontwikkelaars. Het is wel funtioneel, makkelijk voor klanten en bekend bij klanten.

Ja, er zijn modernere, slankere, snellere platforms. Maar dan moet je gelijk aan de slag met zelf veel meer ontwikkelen. Bij wordpress werkt het al of je koopt het voor 100 euro per jaar.

Kortom, volkomen begrijpelijk dat dit nog jaren populair blijft.

[Sn0wblind]

Voor bedrijven welke zichzelf serieus nemen en inkomsten afhankelijk zijn van het platform dat zij draaien is Wordpress misschien wel 1 van de minste keuzen van de populaire producten. Naast een framework hebben is 1 ding in de vorm van bijvoorbeeld een template voor een Wordpress installatie. Content, onderhoud etc zijn misschien nog wel belangrijker. Dus de kostprijs is niet per direct de Wordpress site zelf, het is wat je hier op gaat zetten en wat de kwaliteit van deze content is. Op de lange termijn vereist Wordpress ook gewoon meer onderhoud.

[m-smit]

Wij hebben veel klanten die de editor van wordpress erg fijn vinden. Voor mensen die meer content dan techniek gericht zijn is Wordpress een goede optie. We hebben een koppeling gemaakt om de pagina''s van wordpress in Magento te integreren omdat dat systeem juist erg beperkt is voor het maken van mooie pagina's.

[Sn0wblind]

Ik zou eens kijken naar Storyblok, en dan met name de mogelijkheid om vooraf hele layout blocks op te zetten zodat de content managers op die manier hele page builders tot hun beschikking hebben maar dan fors sneller.

[Reactie gewijzigd door Sn0wblind op 24 juli 2024 15:34]

[mrperson1234]

Dat heeft WP ook sinds vorige maand met de Full Site Editing. Daarmee kan je ook patterns maken. Dus ik denk zelf dat WP zeker nog mee groeit met de huidige tijd.

[Sn0wblind]

Alleen is het langzaam, relatief onveilig versus de concurrentie en doet het nu dingen waar het totaal niet voor gemaakt is.

[DhrRob]

En waarop is deze opmerking gebaseerd, aannames?

[Sn0wblind]

SInds 2004 ervaring in deze industrie voor middelgrote tot internationale bedrijven welke een oplossing ontworpen en gebouwd willen zien.

[litebyte]

Nee, nu snap ik wat u de hele tijd bedoeld Als je zelf iets bouwt is het verdienmodel natuurlijk veel beter...als eh developer.

[Sn0wblind]

Ik stuur een team van developers aan binnen een agency en heb daarnaast nog een eenmanszaak puur uit interesse voor de materie.

[DhrRob]

Aannames dus. Zeg dat dan!

[Sn0wblind]

En waar basseer jij dat op? Aangezien ik 40 to 60 uur per week met deze materie bezig ven van design tot development voor commerciele projecten voor oa beursgetoneerde bedrijven. Wanneer zijn het geen aanames meer?

[kodak]

Wat is er niet meegroeien aan door een update te forceren? In het verleden moesten gebruikers dat zelf maar uitzoeken, met als gevolg dat veel website onveilig bleven.

[Sn0wblind]

Niet het update beleid maar de codebase, de architectuur, de interface etc.

[kodak]

Wat hebben de interface en architectuur volgens jou met de beveiligingsrisico's te maken? Het is namelijk net zo goed gemaakt voor recente architectuur. En dat de interface mogelijk niet prettig voor iedereen werkt is ook niet zomaar een beveiligingsprobleem.
De codebase kan inderdaad een overweging zijn, maar zoals je in dit geval ziet zit het probleem net zo goed in de fouten die ontwikkelaars maken.

[Reactie gewijzigd door kodak op 24 juli 2024 15:34]

[Sn0wblind]

Ik benoem meerdere nadelen waarom je anno 2022 niet meer aan Wordpress zou moeten beginnen. Het hele aan elkaar geplakte gebeuren om een beetje functionaliteit te krijgen doo rmiddel van plugins. Welke weer allemaal javascript libraries mee packagen welke niet kijken of je de library al in een andere plugin hebt zitten etc. Dus zo misschien wel meerdere libraries draait maar dan met mismatched versies en de conflicten die deze met zich mee brengen. Daarnaast is een heel hoop binnen het Wordpress plugin landschap gewoon zo lek als een mandje, in bepaalde gevallen ook mede door de combinatie van plugins. Maar je hebt die plugins allemaal nodig om tot een beetje functioneel platform te komen. Performance maak ik geen woorden aan vuil, is gewoon ruk.

Er zijn gewoon teveel parameters in het huidige Wordpress landschap welke het zeer prijzig maken wil je tot een acceptabel product komen, waarom het dan niet meteen goed doen? Er zijn nu betere tools aanwezig.

[Lrrr]

WordPress heeft standaard gewoon automatische updates aan staan.

[Faloude]

Helemaal mee eens. Toegegeven, heb zeker 3 jaar geen WP site aangeraakt, maar last time I checked: Spaghetti code, geen MVC en grotendeels linear geprogrammeerd.

Bij frameworks met een steilere leercurve heb je vaak in veel minder tijd een extensie gebouwd. Bij WordPress heb je een kortere plattere leercurve maar lever je daar gewoon veel voor in qua code kwaliteit.

[rutger7435]

1 antwoord: https://roots.io
WordPress maar dan zonder alle rommel.

[Sn0wblind]

Thanks voor de tip, ga ik eens induiken!

[delphium]

Het geforceerd bijwerken van een WP-plugin kan alleen als je WP's auto-update hebt aanstaan lijkt me. Wellicht dat op wordpress.com zoiets ook geforceerd kan worden, maar elke gebruiker die zelf host en geen auto-updates heeft aan staan, krijgt niet automatisch nieuwe software.

Waarom is er dan toch commotie hierover? Je kiest er toch voor om WordPress de controle te geven, als je auto-updates aanzet?

[Joecatshoe]

Sinds enkele versies zit er wel degelijk een auto-updater in Wordpress die je (bij een self-hosted standaardinstallatie) niet kan uitzetten, net voor kritische updates aan WP zelf. Kan me inbeelden dat men zo ook plugin updates kan forceren ondanks dat auto-update afstaan.

Uit de blogpost:

Forced auto-updates have also been pushed due to the severity of this issue.

[Reactie gewijzigd door Joecatshoe op 24 juli 2024 15:34]

[delphium]

Sinds enkele versies zit er wel degelijk een auto-updater in Wordpress die je (bij een self-hosted standaardinstallatie) niet kan uitzetten

Nee joh! Een php-app kan alleen actief iets zelf doen middels een (poorman's) cronjob.
Als je de schrijfrechten voor de webserver uitzet, KAN er simpelweg niet worden bijgewerkt. Je heb dus altijd zelf de controle.

[Joecatshoe]

Welja, daarom schreef ik dus "standaardinstallatie". Schrijfrechten beperken op webserver niveau is niet standaard bij een gewone WP installatie. Mijn punt is dat WP weldegelijk gaat proberen auto-updaten zelfs al heb je dat in de instellingen afstaan.

[bartje]

Wat is een geautoriseerde hacker?

[MiesvanderLippe]

Als je een account heb op de blog. Soms kan je die zelf maken, maar meestal moet de eigenaar van de site je toelaten. Ofwel, rottig maar niet echt een onwijs groot toegevoegd risico want het merendeel van de Wordpress auteurs is toch al admin. Vandaar de ophef ook over de geforceerde update.

[Groningerkoek]

Als jij mij een tientje geeft om te proberen op jouw site in te breken om je beveiliging te testen dan ben ik een geautoriseerde hacker.

[bartje]

Pen tester. Maar dat zou voor de kwetsbaarheid toch niks uit moeten maken?

[Groningerkoek]

Ook een pen tester, maar ook een geautoriseerde hacker. En dat staat helemaal los van de kwetsbaarheid zelf.

[cricque]

Tsja als ik logs bekijk van webapplicaties, hoeveel testen er dagelijks niet zijn gebruik je wordpress etc. Dat zijn er echt wel veel. Er zijn genoeg bugs in veel ecosystemen. Het is gemakkelijk en daar stopt het dan voor mij. Veel commotie over dat dit geforceerd is ? Je mag blij zijn dat ze dit doen, want hoeveel mensen gaan effectief ook alles updaten ... Veel sites zijn ooit gemaakt en updates komen er niet, want dat kost geld. Ik maak zelf geen sites meer, maar dikwijls zie je dingen die gemaakt zijn zoveel jaar geleden, nooit iets aan gedaan (copyright etc is meestal een weggever )

[orvintax]

Ja maar dat is toch hun probleem? Die sites die toch niet geupdated worden zitten toch al vol met CVEs. Ik snap wel dat mensen dit niet oke vinden en was zelf ook verbaasd hierover.

[gangsta_playa]

Er is reeds 1.22.4 bij ons geïnstalleerd. Dus er is nog een nieuwe versie uitgekomen.

[prodesk]

Je kunt WP tegenwoordig ook Headless / decoupled gebruiken.

[Boeryepes]

Al dan niet toevallig gisteren opeens 30+ inlogpogingen op mijn wordpress website gehad. Ik gebruik deze plugin trouwens niet.

[RippleXRP]

De plugins vormen in de meeste gevallen het probleem.
Daarom gebruik ik Wordpress ook eingelijk alleen al shell en gebruik ik waar mogelijk geen plugins maar programmeer die fucties zelf in PHP.

[Power2All]

Wordpress is gewoon kudt.
Maar ik snap waarom mensen het gebruiken. Plugin overload, het is een soort van verkapte Windows ME.... als het draait, top, maar als er iets niet goed gaat, breekt het hele systeem...

Ik host er paar sites en zijn een drama bij onderhoud... geef mij maar Symfony en Laravel.

[Reactie gewijzigd door Power2All op 24 juli 2024 15:34]

[innerchild]

Je moet gewoon weten hoe je het moet gebruiken. De meeste simpele en veilgiste optie is om je wordpress website te draaien in een subdomain zegge hoofdpagina.website.nl en dan via een parser plugin de output daarvan naar je www.website.nl te richten. Via deze manier zie je alleen maar de pagina's als een geparste output en niemand weet dat je wordpress gebruikt en ze weten ook niet dat deze pagina's vanuit een subdomain komen laatst staan dat ze weten via wel welk subdomain wordpress draait 🙋‍♂️

[Power2All]

Doet er niet toe.
Gaat om de PHP behandeling van Wordpress en de plugins die van de routing van Wordpress gebruik maken. Daarnaast, zijn veel van die plugins totaal niet optimaal, en gebruiken zo veel meer resources dan zou moeten...

[innerchild]

Doet er wel toe want de uiteindelijke geserveerde pagina's zijn geen wordpress outputs. Dus al is de plugin in wordpress zo brak als wat, dat wat je ziet op de website zijn alleen de pagina's zonder enige link naar wordpress 🙋‍♂️

[Power2All]

Doet er wel toe want de uiteindelijke geserveerde pagina's zijn geen wordpress outputs.

Helaas werkt dat niet helemaal zoals je zou denken.
Dynamische gegevens, inlog/uitlog acties, en noem maar op, verlopen nog steeds via PHP.
Leuk als je een groot gedeelte statisch wilt doen, maar helaas gebeurt er nog steeds een boel niet statisch.
Waar jij op doelt, is een statische website met API systeem, door middel van JavaScript.
Dan kun je beter gewoon naar een geschikte omgeving overstappen zoals Symfony of iets wat daar beter voor geschikt is.