WordPress komt met patch voor bug die auto-update uitschakelde

WordPress heeft een patch uitgebracht voor een bug die in een eerdere versie van zijn software was geslopen. Die heeft tot gevolg dat de auto-updatefunctie niet meer werkt, waardoor nu een handmatige update is vereist. Daarnaast komt er geen patch voor een gepubliceerd DoS-lek.

In een mededeling schrijft WordPress dat de ernstige bug in versie 4.9.3 van zijn software is geïntroduceerd. Die zorgt ervoor dat sites die geconfigureerd zijn voor automatische updates, deze niet meer uitvoeren. Daardoor is het nodig om handmatig te updaten naar versie 4.9.4, die een patch voor de bug bevat. Dat kan onder meer via het dashboard en de knop 'update now'.

In een technische analyse schrijft WordPress dat het de bedoeling was om met versie 4.9.3 het aantal api-verzoeken bij een cron-taak voor een automatische update te verminderen, maar dat door een menselijke fout de bug werd geïntroduceerd. De bug is problematisch, omdat de software bij het uitblijven van een handmatige update geen nieuwe versies meer zal ontvangen. Eventuele kwetsbaarheden blijven daardoor open.

Eerder deze week publiceerde beveiligingsonderzoeker Barak Tawily een beschrijving van een denial of service-lek in WordPress, dat van toepassing zou zijn op een groot aantal sites. Het lek, met kenmerk CVE-2018-6389, laat een ongeauthenticeerde aanvaller via de loginpagina bepaalde php-modules aanroepen en daarmee onder meer grote hoeveelheden css-bestanden opvragen, schrijft beveiligingsbedrijf Imperva. WordPress ziet dit volgens Tawily echter als een probleem dat op server- of netwerkniveau opgelost moet worden. Daarom heeft de onderzoeker eigenhandig een patch geschreven.

Lees meer

IT-banen

Reacties (82)

Erulezz
8 februari 2018 14:38

Gelukkig is er een hele simpele maar effectieve oplossing tegen die DoS bug: wp-login.php alleen toegankelijk maken vanaf een IP Whitelist

. Scheelt ook veel resources omdat je dan gelijk brute force aanvallen niet meer mogelijk maakt.

Voorbeeldje voor Nginx & DirectAdmin;

Custom HTTPd settings -> Domein -> CUSTOM4
_{##########################################

# Restrict wp-login.php access by IP #

##########################################

location = /wp-login.php {

allow from xxx;

deny all;

# PHP config for wp-login.php

try_files $uri =404;

fastcgi_split_path_info ^(.+\.php)(/.+)$;

include /etc/nginx/fastcgi_params;

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include /etc/nginx/nginx_limits.conf;

if (-f $request_filename)

{

fastcgi_pass unix:/usr/local/php|PHP1_RELEASE|/sockets/|USER|.sock;

}

}}

[Reactie gewijzigd door Erulezz op 8 februari 2018 16:40]

Gapert86
@Erulezz • 8 februari 2018 14:53

Alleen onbruikbaar als je zelf of je klant op een dynamisch IP zit. Ik gebruik op Linux zelf een geheime url die ik via een cookie / .htaccess bestand afdwing te gebruiken.

Je maakt in de root een folder aan zoals 'wordpressbeheren' en plaatst daarin een index.php bestand met als inhoud:

<?php $admin_cookie_code="1122334455";
setcookie("WordpressAdminSession",$admin_cookie_code,0,"/");
header("Location: /wp-admin");
?>

Dit plaatst een geheime cookie (pas de cookie code even aan).

Vervolgens, in de root van je website, zet je in je .htaccess bestand een code die controleert of de geheime cookie aanwezig is voordat je mag inloggen;

RewriteCond %{REQUEST_URI} ^/wp-admin/index.php
RewriteCond %{HTTP_COOKIE} !WordpressAdminSession=1122334455
RewriteRule .* - [L,F]

Ik heb het overigens ook wel eens gedaan door de hele /wp-admin map zo te beveiligen, maar sommige plug-ins plaatsen cache bestanden in de /wp-admin folder waardoor je fouten krijgt.

EDIT: Dit is veel minder CPU-hungry dan fail-to-ban of andere plug-ins omdat het native en realtime in apache draait en alleen bij een login-poging.

[Reactie gewijzigd door Gapert86 op 8 februari 2018 15:12]

rlKoekie
@Gapert86 • 9 februari 2018 09:40

Dit klinkt als een redelijke elegante oplossing, dank daarvoor. Maar volgens mij moet er ook een check op de cookie zijn op de wp-login.php page?
RewriteCond %{REQUEST_URI} ^/wp-login.php
RewriteCond %{HTTP_COOKIE} !WordpressAdminSession=1122334455
RewriteRule .* - [L,F]

Ik weet niet of de beveliging op ^/wpadmin/index.php veel nut heeft, als de wp-login.php wel beschikbaar is?

Anoniem: 58485
@Erulezz • 8 februari 2018 14:52

Hoeft niet eens. Fail2ban of wat ik op 15 eigen server gebruik, een script dat om de 5 seconden de Apache status leest en iedere poging tot POST op wp-login.php of /wp-admin/wp-admin-ajax.php opslaat en bij 5 x notering meteen in CSF flikkert.

De IP ban list aan de hand van wordpress is huge geworden in de afgelopen 6 maanden. Gerust een 200.000+ IP adressen.

Gapert86
@Anoniem: 58485 • 8 februari 2018 15:14

Daarom alleen al zou je dit niet moeten doen. Lange IP backlists vertragen je server/website gigantisch. Je IP blacklist in CSF zou maximaal enkele honderden IP adressen moeten hebben. Gewoon via .htaccess een geheime url maken om de admin pagina te verbergen, kost geen CPU-cycles en alle scripts/bots vangen bot. En daarnaast natuurlijk op serverniveau Comodo WAF. Zie hieronder.

[Reactie gewijzigd door Gapert86 op 8 februari 2018 15:16]

Power2All
@Gapert86 • 8 februari 2018 17:14

Heel simpel.
Nullrouting gebruiken inplaats van firewall.
Geen CPU cycles = win.

route add 1.2.3.4 gw 127.0.0.1 lo

[Reactie gewijzigd door Power2All op 8 februari 2018 17:15]

niceman12
@Power2All • 8 februari 2018 17:33

Mag ik vragen wat je hier dan precies mee doet? Als ik er zo even snel naar kijk, forward je de ip (1.2.3.4 is een voorbeeld in dit geval?) naar loopback.
Zou je dit dan in een soort fail2ban script moeten zetten, die automatisch deze route in je IPTABLES zet als iemand 5 keer foutief probeert in te loggen?

Power2All
@niceman12 • 8 februari 2018 18:07

IPTABLES wordt volledig ignored, aangezien als je met die gaat packet droppen, alles nog steeds CPU cycles nodig heeft, voor filtering.
Je past technisch gezien de routing tabel aan, die routeert het IP naar, inderdaad, naar 127.0.0.1, maar het komt technisch gezien erop, dat je het in een zwart gat douwt.

[Reactie gewijzigd door Power2All op 8 februari 2018 18:07]

batjes

Security

@Power2All • 8 februari 2018 18:23

De kernel routing table kost ook gewoon cpu cycles, wel minder dan iptables filteren, maar het is niet geheel overheadloos.

Power2All
@batjes • 8 februari 2018 23:47

Maar de CPU cycles zijn zeer gering als je het vergelijkt met IPTables.
Het gaat erom dat je je CPU niet in overdrive gooit.
Door de routing table te gebruiken, veroorzaak je vele malen minder CPU cycles dan je met IPTables krijgt.

wica
@Anoniem: 58485 • 8 februari 2018 15:14

Wat heeft fail2ban voor nut, als er een lek in WP zit?

wp-login, wp-admin-* achter een whitelist zetten is de meeste veilige optie. Daarvoor heeft WP in het verleden te veel remote bugs gehad.

Gapert86
@wica • 8 februari 2018 15:19

Is dus niet realistisch als je zelf of je klant op een dynamisch IP zit. Beter een geheime url. Zie hieronder.

sdk1985
@Erulezz • 8 februari 2018 18:59

Probleem daarmee is dat websites met bijvoorbeeld WooCommerce of leersystemen wp-login.php nodig hebben om hun website te laten functioneren.

DefaultError
@Erulezz • 8 februari 2018 22:49

Dit whitelisten zou bij de provider standaard ingebakken kunnen worden. Ben je ook in staat om dit te wijzigen mocht je een dynamische IP hebben.

Zelfs een script “24 uurs ban na vijf keer foutief wachtwoord” kan als optie gemaakt worden.

Via de achterkant kun je ook secure de site bewerken om mogelijk je IP te kunnen wijzigen mocht dat nodig zijn.

Douweegbertje
8 februari 2018 18:58

Wel leuk, al die workarounds e.d.
Ik snap best dat je default een aantal security zaken kan regelen. Immers kan je dat altijd doen bij elke applicatie die je draait. Het admin panel afschermen op ip, ratelimit, fail2ban, firewall rules en ga zo maar door: prima.

Wat ik wel schrijdend vind is dat WP dit gewoon niet patched. Ik vind het echt een kul argument; "This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress's control"

Nee, nee. Je hebt een file die toegankelijk moet zijn voor admins-only, hij is public, en je laat het op serverniveau oplossen.

Technisch gezien moet wordpress nu bij de install aangeven: Please mitigate the following issues yourself:
- x , y , z. Maar dat gebeurd natuurlijk óók niet.

WP moet eens realiseren dat dat ze een enorm platform zijn en als ze ZELF niet dingen op orde hebben dat 70% (ik noem maar wat) van de gebruikers kwetsbaar zijn voor basic dingen die WP óók kan oplossen. Die 'onderzoeker' heeft natuurlijk wel een basic dingetje gevonden en het gaat hem vooral om de eer. WP had hem gewoon moeten bedanken, wat goodies moeten sturen en het eens patchen. Wees eens de volwassen partij.

Knippr
8 februari 2018 14:17

Het probleem is natuurlijk nu dat de mensen waarvoor auto update juist het allerbelangrijkst is, mogelijk deze patch nooit installeren. En laat dat mogelijk maar weg.

servies
@Knippr • 8 februari 2018 15:18

Het gekke is dat mijn eigen site wel automatisch is geüpdate naar versie 4.9.4...

gooos
@servies • 8 februari 2018 23:02

Bij mij zijn ook al mijn sites automatisch van 4.9.3 naar 4.9.4 geüpdate maar dat zal wel door de auto update functie van Installatron (op DirectAdmin) zijn getriggered.

Frenziefrenz
@servies • 8 februari 2018 15:27

Vanaf 4.9.2 wellicht?

walteij
@Knippr • 8 februari 2018 14:21

Zolang die mensen zelf op het backend van Wordpress inloggen, is er niets aan de hand.
Het eerste wat je namelijk ziet als je inlogt op Wordpress nu is boven aan een notificatie: Upgrade to Version 4.9.4 now.

Dus alleen mensen die geen content aan hun website toevoegen (wat een beetje vreemd is voor een blog site) zullen niet geupdate worden.

[Reactie gewijzigd door walteij op 8 februari 2018 15:42]

Basszje
@walteij • 8 februari 2018 14:26

Je zou eens moeten weten

Vooral in de categorie klein bedrijf met contactgegevens en google map.

Zoop
@Basszje • 8 februari 2018 14:41

Makkelijk 3 kwart van de Wordpress sites waar ik op mijn werk mee te maken krijg zijn zwaar verouderd. In veel gevallen auto-update niet eens aan (dus hebben we deze bug niet voor nodig).
Of plugins die niet meer maintained zijn en al jaren bekend is dat ze gigantische lekken en exploits bevatten.

We hebben dan ook soort van een regel dat we nooit het onderhoud van zulke bestaande sites op ons nemen, dan bouwen we liever een nieuwe. Er kan zo gigantisch veel zooi in zitten (heb het allemaal wel een keer gezien inmiddels).

Veel van die sites zijn gebouwd met het idee dat de klant deze zelf onderhoud, maar als ze dan bij ons komen is dat juist meestal omdat ze die site al jaren niet aangeraakt hebben (leuk, met een blog erop enzo en laatste post is uit 2013).

Nog niet zo gek lang geleden een wordpress site overgenomen (met het plan deze tzt een nieuwe te bouwen). Even oppervlakkig updates gedraaid en niet veel verder gekeken (bedoel, dat ding gooien we later toch weer weg). Weekje later meldingen van me hostingprovider dat er allerlei phishing zooi in zit...

Wordpress is erg praktisch om snel iets in elkaar te zetten, maar de kwaliteit van de gebouwde sites zit echt gigantisch veel verschil in en daarnaast is er dankzij de populariteit ook ontzettend veel zooi voor te vinden.

Basszje
@Zoop • 8 februari 2018 15:23

Dat klopt idd. Eigenlijk zou je altijd een service-pakket moeten meeverkopen met een website. Te weinig klanten hebben daar zin in helaas. Het is toch een eigen verantwoordelijkheid.

Maar het is niet anders bij andere frameworks, het draaien van Windows XP of dergelijk. In de IT is het bijblijven geblazen.

Zeker in het MKB is het toch een hoog digibeet gehalt. Men installeert alle zooi die ze ergens kunnen vinden, betalen voor onderhoud ho maar, maar gaat het fout dan is het de schuld van de software, de leverancier etc.

joldemans
@Basszje • 8 februari 2018 18:54

Ik heb dit opgenomen in m’n hostingpakket prijs. Alle sites die ik zelf ontwikkel worden meegenomen in het update systeem.

Gebruik sinds kort managewp.com om een groot deel van de sites tegelijk van updates te voorzien. Scheelt bakken tijd

walteij
@Basszje • 8 februari 2018 14:30

True....

The.Terminator
@walteij • 8 februari 2018 14:33

Zoals Basszje zegt, het probleem is dat heel veel (vooral kleine) bedrijven Wordpress niet als blog gebruiken.

Die bedrijven gebruiken het bijna als statische website waar men heel soms een item toevoegd of content update.

wica
@The.Terminator • 8 februari 2018 15:18

Ik zie het ook bij grotere bedrijven. Die van een andere partij weer een stukje software kopen om op hun sub website te zetten. Waarin weer een WP verwerkt zit.

Deze worden vaak niet automatische geüpdatet, naar de laatste WP versie of er gaat op zijn minst een paar weken over heen.

Basszje
@wica • 8 februari 2018 15:24

Ik vraag me eerlijk gezegd ook wel eens af of sommigen niet gewoon beter af zijn met een statische pagina in ouderwets HTML + CSS. In sommige gevallen ben je langer bezig alles in een framework te prutsen dan je bezig bent met een statische pagina.

Zoop
@Basszje • 8 februari 2018 15:37

Tsja, maar dan mag je basis html uitleggen aan diegene die het af en toe eens moet updaten (wat dan in de praktijk eens in de 2 jaar voor komt ofzo, in dat geval mag je de wijziging ook aan mij geven, zet ik het er wel op).

Dit is zo'n beetje de main issue, want de klant eist nogal snel dat ze het zelf moeten kunnen bijwerken, dus wordt er werk gestoken in het ontwikkelen / deployen van een cms om er dan achter te komen dat ze het sindsdien nooit meer hebben aangeraakt, of gigantisch zitten te verkloten (zoals gigantische teksten zetten op plekken waar er niet veel ruimte is, en dat dan verder ook niet controleren), in het geval van WP nooit een admin account geven (tenzij je je klant echt kan vertrouwen) want dan staan er binnen no-time de meest wazige plugins op. Ik heb het zelfs een keer meegemaakt dat de klant zelf een thema had geïnstalleerd (terwijl wij er juist helemaal op maat en naar wens een hadden ontwikkelt), thema functioneerde goed (genoeg) en de klant vond het mooi ... prima ... wezenlijk heb je nu een WP-installatie van een paar duizend euro gekocht, maar goed ...

Dusja, streng afbakenen wat ze wel en niet mogen en iets van een onderhoud/service contract aanbieden zodat die sites nog met enige regelmaat gecontroleerd worden

batjes

Security

@Zoop • 8 februari 2018 18:41

De site zelf hoeft niet basis html.

Desnoods gebruik je een stukje PHP om troep die ze zelf eventueel willen updaten of toevoegen uit tekstbestandjes, buiten de webroot map, wordt ingelezen.

Zo ook wel eens een site gemaakt voor iemand waarvan enkel de prijzen 1 keer per jaar gewijzigd werden en de homepage info konden aanpassen, en dit wilde ze zelf kunnen doen(heb het de meeste jaren voor ze gedaan). HTML/CSS/JS hoeven ze niet te kunnen, een tekst documentje openen en prijs1=100, prijs2=300, tekstvlaklinksboven="lorem ipsum", tekstvlakmidden="lorem ipsum", etc aan te passen, dat lukt mensen nog wel.

Nu deed ik op de achtergrond moeilijker, paar security checks en trok de info uit het bestand en duwde het een database in, zodat het scriptje zo min mogelijk buiten zijn webroot mapje zat te klooien, en het werkte gewoon wat sneller.

MySQL, PHP en IIS up to date houden regelde Windows voor me. Dus daar zat verder geen omkijken meer aan.

[Reactie gewijzigd door batjes op 8 februari 2018 18:42]

Zoop
@batjes • 8 februari 2018 18:57

Ik heb dat lang lang geleden ook wel meermaals op zon manier gedaan. Het was mij nu niet eens als optie te binnen geschoten, zegt wellicht ook wat over mij als developer dat ik zelf ook vrij snel geneigd ben er iets van een cms tegenaan te kwakken (iets “simpels” is al vrij snel minstens een Symfony project).

Ligt namelijk sterk aan je klant / afnemer of je zoiets zoals jij voorstelt kan gebruiken. Je moet toch een beetje uitkijken met het escapen van specialchars (zeker je quotes, anders gaan je vars al stuk), of gebruik van html voor breaks, paragraven en stijlen, niet bepaald foolproof. Als je klant klein beetje technisch is, zal het vast prima zijn. Veel van mijn klanten zijn dat in ieder geval niet.

Neemt niet weg dat de meeste websites gewoon prima zouden zijn als een statisch paginaatje. Als deze fotograaf het niks kan interesseren, dan moet hij ook niet grote delen van zijn werk en klanten bestand erop knallen maar een simpele one-pager met wat contactgegevens en klaar. Hou je klantenbestand maar bij in een excelsheet op je computer ofzo.

[Reactie gewijzigd door Zoop op 8 februari 2018 18:59]

Basszje
@Zoop • 8 februari 2018 17:16

Tja, klant is koning uiteindelijk. En die wil CMS + admin rechten en geen servicecontract.

Op zich zijn de nieuwe regels qua datalekken al een stap in de goede richting, maar wellicht dat nalatigheid op dit vlak ook aangescherpt kan worden.

Punt is dat de klant eerst moet leren nadenken over IT-issues. En je kan ook niet te moeilijk doen want voor jou 10 andere bureaus die zo een WP-tje ergens neerplempen.

wica
@Basszje • 8 februari 2018 15:34

Ben ik mee eens, maar dat is niet hip

sdk1985
@The.Terminator • 8 februari 2018 19:05

Zoals Basszje zegt, het probleem is dat heel veel (vooral kleine) bedrijven Wordpress niet als blog gebruiken.

Die bedrijven gebruiken het bijna als statische website waar men heel soms een item toevoegd of content update.

In mijn ervaring zijn van elke 100 wordpress websites in Nederland er 99 geen blog. De aanzuigende kracht is groot. Thema's maken de statische pagina's mogelijk en de eindklant kan makkelijk de inhoud achteraf aanpassen. Nadeel is dat veel websites hierdoor tegenwoordig van plugins aan elkaar hangen, 30+ is geen uitzondering. Met alle gevolgen van dien... (security, snelheid, complexiteit). Zal niet snel veranderen, een beter alternatief is er eigenlijk niet.

[Reactie gewijzigd door sdk1985 op 8 februari 2018 19:06]

WhatsappHack

Netwerk en systeembeheer
Security

@Knippr • 8 februari 2018 14:25

Jup. Het merendeel van die mensen kijkt daar nooit meer naar om. Daar ligt een taak voor hosting providers om hun klanten te informeren.

Ikzelf gebruik auto-update niet overigens, staat uit op alle wordpress sites die ik onderhoud. Dat is namelijk incompatible met de verhoogde veiligheidsinstellingen en ik zie liever eerst wat er allemaal wijzigt.

Not to mention eerst een goede backup maken.

kevinwalter

@WhatsappHack • 8 februari 2018 14:31

Tip: Ga eens kijken naar MainWP. Ik heb dit lek ook gevonden door de Vulnerability checker extensie. Ideaal om toch te updaten en je beveiliging op orde te hebben!

WhatsappHack

Netwerk en systeembeheer
Security

@kevinwalter • 8 februari 2018 16:03

Het probleem is voornamelijk dat door security hardening bepaalde database updates niet uitgevoerd kunnen worden tijdens de WP-update. Voor een update moeten eerst server-side de benodigde rechten worden gegeven en dán pas kan de updater draaien, daarna worden de rechten weer ontnomen. Ik denk als ik het zo lees dat MainWP daar geen verandering in zal brengen.

kevinwalter

@WhatsappHack • 9 februari 2018 07:19

Jep, dat is een hele andere zaak. Voor normale installaties werkt het echter prima! :-)

MrHarry
8 februari 2018 14:05

voor een gratis CMS is wordpress toch echt wel een topper. En support wat ze bieden al helemaal.
@thePiett voor iets wat gratis is mogen we niet klagen

FlyingDutchMen
@MrHarry • 8 februari 2018 14:14

Volledig mee eens! Dit is echt een mooi voorbeeld van een goede community die ervoor kan zorgen dat er een mooie tool die komt die goed onderhouden wordt en ook nog eens goede ondersteuning bied.

kuurtjes
8 februari 2018 14:02

Ah, dus het update mechanisme vanuit het admin paneel werkt nog wel goed. Alleen het automatisch updaten was kapot. Makkelijk dus voor mensen die er wat minder van kennen

Get!em
@kuurtjes • 8 februari 2018 22:02

Klopt helemaal. En wat ik gezien heb, is dat de 4.9.4 ook er toch automatisch op komt. Ik kreeg in iedergeval netjes melding van auto update naar 4.9.4. En de geschiedenis laat zien dat 4.9.2 op 17 jan en 4.9.2 op 5 feb zijn geinstalleerd (via de auto update). Wel ook de NL_NL versie.

[Reactie gewijzigd door Get!em op 8 februari 2018 22:05]

Basszje
8 februari 2018 14:25

Ik vind het wel vreemd dat ze niets doen tegen die DoS mogelijkheid aangezien het vrij simpel op te lossen is.

Ter toevoeging, de URL roept niet alleen CSS modules aan, maar *alle* ingebouwde CSS / JS libraries, en dat zijn er nogal wat.

kevinwalter

8 februari 2018 14:27

Voor het DoS lek, er is ook een plugin die dit tegengaat!

https://wordpress.org/plugins/wp-cerber/
"Protection against (DoS) attacks (CVE-2018-6389)."

Olaf van der Spek
8 februari 2018 14:04

maar dat door een menselijke fout de bug werd geïntroduceerd.

Wat voor zin / nut heeft deze qualificatie?
Als het een aap was geweest, was het het vermelden waard geweest maar nu?

[Reactie gewijzigd door Olaf van der Spek op 8 februari 2018 14:04]

Joeri Harleman
@Olaf van der Spek • 8 februari 2018 14:21

Oneens. Als men dit had weggelaten vroeg men zich af hoe zo’n fout gemaakt kon worden.

walteij
@Joeri Harleman • 8 februari 2018 14:25

Nu is het duidelijk dat een van de programmeurs een foutje heeft gemaakt en dat deze bug er dus niet 'expres' in is gezet (vanwege een onbekend ander lek of zo) en kunnen de alu-hoedjes weer verder gaan met samenzweringen van de NSA zoeken (sorry mensen, ik ben vandaag in een erg melige bui en mijn reacties van vandaag zijn dus ook niet al te serieus te nemen).

Frenziefrenz
@Olaf van der Spek • 8 februari 2018 14:19

Tja, zo schrijven ze het zelf. 't is ook maar een uitdrukking.

https://make.wordpress.or...se-the-technical-details/

Unfortunately due to human error, the final commit didn’t have the intended effect, and instead triggers a fatal error as not all of the dependancies of find_core_auto_update() are met. For whatever reason, the fatal error wasn’t discovered before 4.9.3’s release – it was a few hours after release when discovered.

Anoniem: 1039433
8 februari 2018 18:57

Jongens, ik weet het, je houdt van vulgaire meisjes
Hoe zit het met online-communicatie met hen zonder grenzen? Hier http://mataxa.tk vind je geile echte meisjes uit verschillende landen.

Emin3m
@thePiett • 8 februari 2018 14:40

"de uit elkaar vallende", dat durf ik niet zomaar te zeggen met zo'n community, respect.

mjz2cool
@thePiett • 8 februari 2018 14:51

bedoel je niet een cms die heel wat minder goed onderhouden wordt, en die niet een hele communitie erachter heeft?

shades
@thePiett • 8 februari 2018 14:25

Ik las de titel en was gelijk al bang voor dit soort onzinnige en nutteloze posts. Loze negatieve kreten in het rond strooien is makkelijk - onjuistheden zijn altijd slecht te onderbouwen zoals je inderdaad niet doet. Wordpress doet wat het moet doen...
edit:typos

[Reactie gewijzigd door shades op 9 februari 2018 08:50]

Tielenaar
@shades • 8 februari 2018 14:42

Er is inderdaad een gebrek aan onderbouwing, maar er zijn wel een kern van waarheid in. De architectuur van Wordpress is vrij ouderwets en getuigt niet echt van een kijk op de toekomst. Wordpress is daarom in mijn ervaring ook alleen geschikt voor sites zonder al te veel functionaliteit, want over het algemeen moet je het doen met wat het out of the box biedt, met een leuk sausje eroverheen. Wil je uitgebreide functionaliteit met databaselogica en ander vormen van interactie, dan kan je beter bij een rigide (en log) CMS als Drupal aankloppen.

servies
@Tielenaar • 8 februari 2018 15:16

Yup... al die uitgebreide functionaliteit die 99,9% van de mensen stiekem toch niet gebruikt en die alleen maar problemen kan veroorzaken...

thePiett

@shades • 9 februari 2018 12:02

Hier is je onderbouwing: https://github.com/WordPress/WordPress .

Los van de dramatische code (met alle gevolgen van dien) zegt het feit dat deze repository een SVN-sync is en dat Trac wordt gebruikt voor de development workflow dat Wordpress aan alle kanten een oude roestige uit elkaar vallende auto is waar je ver vandaan moet blijven.

kmichael
@thePiett • 8 februari 2018 14:02

Wat moet het dan zijn voor een simpele site?

Tielenaar
@kmichael • 8 februari 2018 14:38

Puur omdat er geen beter alternatief is betekent natuurlijk niet per definitie dat het goed is.

thePiett

@kmichael • 9 februari 2018 12:03

Iets van een flat file CMS zoals Grav, Kirby of Statamic.

sdk1985
@Gapert86 • 8 februari 2018 19:01

Bij Joomla is enkele jaren geleden de community helemaal leeg gelopen. Veel cruciale plugins rondom zaken als cralwlen, caching en seo begonnen brak te worden en alternatieven waren er niet meer.

Zoop
@Gapert86 • 8 februari 2018 15:42

Joomla zit wat mij betreft in exact dezelfde categorie als Wordpress.
Dus de afweging om de een te gebruiken boven de ander is grotendeels voorkeur (er zijn zoveel plugins beschikbaar dat ze praktisch dezelfde functionaliteiten kunnen bieden).

Daarom krijg je minnetjes, denk ik, bovendien onderbouw je zelf ook niet waarom Joomla een betere keus zou zijn dan Wordpress.

Gapert86
@Zoop • 8 februari 2018 15:56

Ik onderbouw het met mijn eigen ervaring zoals je ziet, als je goed leest. Wat wil je nog meer? Een bron die zegt dat Joomla beter is? Het blijft een kwestie van voorkeur en usecase.

Overigens zou je Joomla niet in dezelfde categorie plaatsen als je beide systemen wel eens hebt gebruikt voor iets meer dan een blog.

[Reactie gewijzigd door Gapert86 op 8 februari 2018 15:57]

Zoop
@Gapert86 • 8 februari 2018 15:59

stukje flexibeler, stabieler en functioneler.

Dat is geen onderbouwing

Je legt niet uit waarom dat zou zijn, bovendien is het nog niet eens per definitie waar.

En ja, heb zowat elk bekend blogsysteem en cms gebruikt en heb er dagelijks mee te maken.
Wordpress kan ook behoorlijk meer dan alleen een blog (dus right back at ya, dat zou je weten als je het zou gebruiken voor meer dan een blog).

Gapert86
@Zoop • 8 februari 2018 16:26

Zijn vraag rechtvaardigt een antwoord gebaseerd op puur ervaring.

Wij gaan hier niet uit komen. Hopelijk dupeer je niet teveel klanten met het gebruik van Wordpress voor websites die veel meer zijn dan een blog.

[Reactie gewijzigd door Gapert86 op 8 februari 2018 16:28]

Zoop
@Gapert86 • 8 februari 2018 16:49

Oh maar ik zeg niet dat ik geen Joomla gebruik en enkel alleen Wordpress hoor, dat is jou aanname.

Maar iemand loopt Wordpress af te zeiken, dan wordt er gevraagd wat er dan beter is, en jij zegt Joomla (zonder dat te onderbouwen) terwijl dat wel degelijk in dezelfde categorie valt.

Nergens voor nodig om gelijk zo persoonlijk dat ik mijn klanten zou duperen.
(terwijl Wordpress vaak juist de lading dekt, en Joomla al heel snel overkill is, dus erg zwak en kort door de bocht reactie van je).

Er valt helemaal niks uit te komen, je zat verkeerd, je werd gecorrigeerd en nu doe je kribbig.

Overigens houd ik mij met name bezig met het maken van op-maat cms systemen die buiten standaard paketten vallen. Wordpress en Joomla enzo is voor de stagiares om mee te knutselen.

[Reactie gewijzigd door Zoop op 8 februari 2018 16:54]

Gapert86
@Zoop • 8 februari 2018 16:57

“Wordpress en Joomla enzo is voor de stagiares om mee te knutselen.”

Dit zet de rest van je opmerkingen in perspectief. Bedankt.

Zoop
@Gapert86 • 8 februari 2018 17:06

Ik zou de gang van deze reacties eens even teruglezen als ik jou was.
Ik deed vriendelijk, probeerde je iets uit te leggen, en jij gaat gelijk op de man spelen en komt met onvriendelijke reacties en wilde aannames ("dat zou je weten als...", ik doe dit werk al 20 jaar, je hoeft me echt niets te vertellen)
Dat zet het voor mij in perspectief, gewoon een onvriendelijke chagrijn die niet echt weet waar hij het over heeft.

basdej
@Gapert86 • 8 februari 2018 14:09

Joomla is ongelofelijk complex, waar wordpress de gebruiker makkelijk de weg wijst.

[Reactie gewijzigd door basdej op 8 februari 2018 14:10]

aadje93
@Gapert86 • 8 februari 2018 20:07

mag mezelf toch wel redelijk handig noemen denk, maar joomla kreeg ik amper wat voor elkaar wat ik wilde. op WP had ik dit vrij vlot met enkele plugins geregeld, waarbij ik nu amper werk heb gezien mijn index pagina's makkelijk werken door de catogerie/tag manager van een "blog" platform, terwijl mijn site statisch gebouwd is (doch artikelen in berichten ipv pagina)

walteij
@Gapert86 • 8 februari 2018 14:19

Joomla is volgens mij overkill voor een simpele site.
En hoewel Joomla zelf minder vulnerabilities heeft dan Wordpress, hebben de Joomla plugins wel meer vulnerabilities dan die van/voor Wordpress. Never mind, hier zat ik dus helemaal fout, Oorzaak: Resultaten uit het verleden bieden geen garantie voor het heden of de toekomst.

[Reactie gewijzigd door walteij op 8 februari 2018 14:37]

walteij
@Gapert86 • 8 februari 2018 14:36

De laatste keer dat ik actief met Joomla heb gewerkt was nog met versie 2.x. En daarin waren er heel veel plugins met kwetsbaarheden, waar ik mijn uitspraak op heb gebaseerd.

Even de plugin vulnerability lists vergeleken, joomla en Wordpress en ik geloof dat ik inderdaad mijn woorden moet terugnemen.

servies
@walteij • 8 februari 2018 15:14

Mwoah... als je bij de WP lijst kijkt dan zie je versienummers er bij staan tot wanneer de kwetsbaarheid aanwezig is, deze versies zijn er ook niet meer.
Bij de Joomla lijst ontbreekt dat en staat er dat het open vulnerabilities zijn..., en dat suggereert dat de kwetsbaarheden in plugins uit 2013 nog steeds bestaan. Bij wordpress kan ik oudere versies niet meer automatisch downloaden/installeren vziw.

aadje93
@thePiett • 8 februari 2018 14:01

die uit elkaar vallende roestige auto werkt anders prima

MineMine
@thePiett • 8 februari 2018 14:13

Een menselijke fout gemaakt, waardoor de update bug komt, en binnen 1 dag een patch om de bug te fixen.

Toch netjes & snel voor een roestige oude auto.

GekkePrutser
@MineMine • 8 februari 2018 14:53

Plus, dit was helemaal geen vulnerability. Gewoon een bugje waarbij je op een knop moest drukken. Boeiend

Storm in een glas water.

Goed om te weten hoor, en ik vind het tof dat Tweakers hier aandacht aan besteedt. Maar het zegt niet veel over de betrouwbaarheid van Wordpress.

mjz2cool
@thePiett • 8 februari 2018 14:50

inderdaad, het gaat in het artikel alleen maar over een automatisch update systeem wat niet werkte door een bug. en voor degene die echt een uitgebreide website heeft maakt het weinig uit, want met updates krijg je ook weer compatibiliteitsproblemen, dus wordt het waarschijnlijk toch al veel handmatig gedaan.

aadje93
@thePiett • 8 februari 2018 14:03

en die roestige auto heeft zich goed bewezen, genoeg "moderne" motoren met meer problemen dan de oude motoren, te kleine keerringen (bekend duits merk) spontaan klappende kettingen, noem het maar op

1 2 Volgende

Op dit item kan niet meer gereageerd worden.

WordPress komt met patch voor bug die auto-update uitschakelde

Lees meer

IT-banen

Reacties (82)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden