WordPress 5.5 kan plug-ins automatisch updaten

WordPress maakt het in de nieuwste versie 5.5 mogelijk plug-ins automatisch te updaten. Ook thema's kunnen automatisch worden bijgewerkt. Het wordt daarnaast ook mogelijk updates uit te voeren door een zip-bestand te uploaden.

De veranderingen zitten in versie 5.5 van het content management systeem, dat WordPress Eckstine noemt. In die versie wordt het mogelijk om automatische updates in te schakelen voor zowel plug-ins als thema's. Het gaat om een opt-in-functie. Gebruikers kunnen in één keer alle plug-ins laten autoupdaten, of dat per plug-in of thema inschakelen. Het is daarnaast ook mogelijk om een update handmatig uit te voeren door een zip-bestand met een recente versie van de plug-in te uploaden.

WordPress 5.5 is ook de eerste versie van het cms die een ingebouwde sitemap krijgt. Daarnaast voegt WordPress 'lazy loading' toe. Daarbij worden afbeeldingen pas geladen op het moment dat gebruikers erheen scrollen. Dat zou de laadtijd van websites sneller moeten maken.

WordPress is het meestgebruikte cms ter wereld en staat op miljoenen websites geïnstalleerd. Er ontstaan vaak veiligheidsincidenten doordat kwetsbaarheden in plug-ins worden uitgebuit. Veel sitebeheerders updaten die niet waardoor websites kwetsbaar worden. Het was al wel mogelijk het cms zelf automatisch bij te werken, maar de plug-ins zelf nog niet.

Reacties (63)

[Yzord]

Persoonlijk raad ik de auto updates van plugins af. De laatste tijd komen steeds meer hints naar voren dat goedlopende plugins door criminelen worden opgekocht voor een leuk centje en krijgt de volgende update vaak een malware versie. Schijnt behoorlijk lucratief te zijn.

Zelfde als extensions voor browsers. Dus kijk uit met auto updates.

[mpol]

Ik snap je zorgen.
Het probleem van het verkopen van plugins waarbij er dan plotseling spam in de nieuwe versie van die plugin komt speelde een aantal jaren geleden. Volgens mij zijn de plugin maintainers en ook het plugin team van WordPress hier nu wel scherp op. De afgelopen 2 jaar heb ik niet gehoord dat dit opnieuw gebeurd is.

Mocht je je afvragen of auto-updates voor jou interessant zijn of juist niet, de mensen van WordFence hebben een uitgebreid artikel geschreven met alle voors en tegens, en ook voor welke doelgroepen het waarschijnlijk wel goed kan zijn, en voor welke niet:
https://www.wordfence.com...what-do-you-have-to-lose/

[kodak]

En hoe weegt dat zwaarder dan plugins die updates nodig hebben omdat de ontwikkelaars er fouten in blijven maken terwijl de gebruikers niet goed zijn in updaten?
Het lijkt mij niet handig om zowel bij het niet-automatisch updaten als bij het automatisch updaten alleen daarop te vertrouwen om je wp-site veilig en zo bugvrij mogelijk te houden.

[Reactie gewijzigd door kodak op 26 juli 2024 11:59]

[litebyte]

Beide kinderen van mij hebben een Wordpress site (want ze mogen geen facebook) en dat gaat eigenlijk al jaren prima. Wel is het zo dat het update beleid van plugins nog wel eens wat aandacht vraagt. Handig als zo'n functe een keuze is, en vooral als je dit per plugin kan instellen.

[Verwijderd]

Dat kan! In het plugin menu kun je aangeven of ze automatisch updaten of niet.
Standaard staat dit volgens mij voor alle plugins aan.

Er zijn trouwens al jaren plugins waarmee je dit heel eenvoudig aan kon zetten overigens. Advanced Automatic Updates is een plugin die door een core team dev gemaakt is, die als basis gediend heeft om deze functionaliteit in WP Core te krijgen. Destijds heeft de functionaliteit echter geen UI interface gekregen, maar om dat relatief simpele stukje via UI beschikbaar te maken hebben twee andere core devs de plugin Update Control gemaakt.
Beide plugins geven echter enkel de optie om alles aan of uit te zetten, dus de toevoeging van deze specifiekere "per plugin" optie is wel fijn.

[mpol]

Correctie; standaard staat het uit voor plugins en thema's.

En wat ik begrijp is er het plan om ook voor major auto-updates van WordPress een user-interface te maken voor WordPress 5.6, die nog dit jaar uit komt.

[litebyte]

Dank, ja de AAU plugin kende ik al wel, maar dat het nu onder WP mogelijk zelf valt lijkt me een betere (misschien ook veiligere) oplossing.

[Verwijderd]

AAU is destijds uitgewerkt om te integreren in Core. De hele functionaliteit van de plugin is er niet in terecht gekomen voor zover ik weet, maar in ieder geval wel de basis ervan.
Ik vond het zelf altijd erg jammer dat er niet direct UI in de Settings voor is gemaakt om het makkelijker toegankelijk te maken voor gebruikers. Het kan wel aangezet worden door in de settings.php file aanpassingen te maken, maar ik ben daar zelf niet zo'n fan van. Als je zoiets doet, maak het dan makkelijker te gebruiken door er een UI setting voor te maken. Dat was het principe ook achter de Update Control plugin.

@mpol
Dank je voor de correctie!
Ik heb ze wel gelijk aan staan, maar waarschijnlijk komt dat doordat ik zelf Update Control al op auto updates had staan.
En inderdaad; WP 5.6 staat voor aankomende december gepland in de huidige roadmap.

[TERW_DAN]

Je kunt het per plugin instellen als je dat wilt.

[borbit]

Hoe is een Wordpress site een alternatief voor Facebook?

[litebyte]

Delen wat ze (dagelijks) doen ipv via instagram/facebook.

[sus]

Offtopic hoor, maar wat doen ze dan op hun wordpress site? Schrijven ze daar hun ding met fotouploads enzo? Puur interesse, heb er hier ook 2 rondlopen die vanzelf iets op internet gaan doen.

[litebyte]

Klopt inderdaad, vooral dan veel foto en video (link via youtube) uploads. Ze hebben ieder hun eigen blog. Moet wel bekennen dat mijn dochter er het laatste jaar nog weinig mee doet, maar mijn zoon is er nog wel veel actief mee.

[Oon]

Heb je dit dan ook doorgetrokken en ze in ieder geval zelf de mogelijkheid tot het aanpassen van templates en stylesheets gegeven, of is het puur een blog?

[litebyte]

Nee, niet echt. Het gaat er de kinderen om zo snel mogelijk hun foto's vidoes te kunnen plaatsen en linken. Voor mij is het belangrijkste dat beide sites facebook-vrij zijn, dus er staan natuurlijk ook geen 'facebook like' links op.

[mikesmit]

Beide kinderen van mij hebben een Wordpress site (want ze mogen geen facebook)

Ik snap je afkeer voor Facebook maar denk je dat je dit voor eeuwig kan tegenhouden? Sociale media zijn populair door het “sociale”, de groepsdruk zal op een gegeven moment te groot worden

[HerrPino]

Zijn er jongeren die uberhaubt nog facebook gebruiken? Ik krijg van mijn kids het idee dat het voornamelijk 35-plussers zijn.

[mikesmit]

Zou best kunnen . Ik heb dan wel een account maar doe er vrij weinig mee. Het is meer een soort adresboek voor vage kennissen enzo.

Ik had overigens wel door dat Instagram, Snapchat en tiktok een stuk populairder zijn geworden.

[dumbledore]

Inderdaad, ze gebruiken Instagram maar dat komt dus op t zelfde neer..

[litebyte]

We zijn als ouders echt niet tegen social media, en zoals Herr Pino hieronder aangeeft, facebook wordt weinig nog door tieners gebruikt. Maar instagram is dan een ander verhaal en dat gebruiken ze dus ook niet.

Onze kinderen wonen het grootste deel van het jaar niet in Nederland, en is Pinterest en Twitter (wat ze wel gebruiken) populairder dan Facebook

[Reactie gewijzigd door litebyte op 26 juli 2024 11:59]

[litebyte]

Hahaha, okay dat van dementie wist ik dan niet . Het gaat ons om de privacy. We zijn absoluut niet tegen social media of gebruik, maar facebook/instagram dat staan we niet toe.

[danieloc]

Ik denk niet dat je wordt gedownvote omdat je reactie te direct is. Je plaatst een flinke claim, namelijk dat mensen door Facebook dementie krijgen en asociaal worden (ik denk dat je hier anti-sociaal bedoelt).

Als je met dit soort claims komt, zorg dan in ieder geval dat je hier een wetenschappelijk artikel o.i.d. bij linkt.

[Orgel]

Dit soort claims onderbouwen kan niet omdat een wetenschappelijk artikel pas te maken is over 30 jaar als we meer weten wat de werkelijke gevolgen zijn van social media en bijv. de hele dag een mobiel in je buurt. Straling enzo. Tweakers moeten namelijk altijd maar een onderbouwing maar zelfs met Covid is er amper een onderbouwing.

[kftnl]

Lazy loading maakt laadtijd sneller? Nog nooit meegemaakt, meestal ben ik dan juist elke paar centimeter scrollen aan het wachten. Sites als die van Albert Heijn zijn daar vrij extreem in.

Het bespaart denk ik wel bandbreedte

[Reactie gewijzigd door kftnl op 26 juli 2024 11:59]

[Verwijderd]

Jawel.

Als je een pagina opent met 50 foto's zonder lazy loading, dan laadt jouw browser wellicht onnodig 49 foto's omdat je toch alleen geinteresseerd bent in die eerste foto.

Wanneer lazy loading ingeschakd staat, weergeeft ie alleen de foto's op het vlak dat je staat. Dus de 49 a 48 foto's laadt ie niet. Het is win voor beide, want het bespaart bandbreedte.

[kftnl]

Dus als het 50 foto's van 300kB zijn bespaar ik een seconde op 4G... Of 0.1 seconde thuis. Gezien browsers de assets die ze het eerste tegenkomen als eerste laden, worden meestal de items die ik als eerste zie ook nog eens als eerste geladen - dus al is de verbinding traag gaat het nog steeds prima.

En om die seconde te besparen kan ik niet meer normaal door de pagina scrollen - en ben ik daardoor vaak veel meer tijd kwijt.

Dat het de provider bandbreedte kan besparen klopt natuurlijk.

[Reactie gewijzigd door kftnl op 26 juli 2024 11:59]

[Saven]

Tegenwoordig schijnt het ook impact op je SEO te hebben, en dat Google z'n page speed checker daar ook naar kijkt helpt helaas niet mee.

Maar aan de andere kant, het is ook fijn dat je niet 20 seconden langs linksonder in de browser ziet dat hij nog aan het wachten is op xxxx.server.com

[Verwijderd]

Nee,

Ze hebben recent uitgelegd in een video, dat ze niets met de data van o.a lighthouse doen waarmee ze de snelheid van je website bepalen.

Ik volg het ook niet meer. Eerst introduceert google een product en hamert op snelheid, vervolgens allerlei geruchten over seo, en uiteindelijk verklaren ze zelf dat (nog) niet te gebruiken. Het heeft wel nut, daar niet van. Bezoekers willen iets snels nu eenmaal.

[Saven]

Toevallig linkje naar die video? Kan ik dat ook weer aan mn klanten laten zien zonder de hele discussie met ze aan te gaan

[phex]

Source?

[Croga]

Dus als het 50 foto's van 300kB zijn bespaar ik een seconde op 4G... Of 0.1 seconde thuis.

Het laden van een plaatje is nagenoeg niet afhankelijk van het formaat van het plaatje. Het request zelf duurt over het algemeen vele malen langer dan het daadwerkelijke data verkeer. Dus nee, zo eenvoudig kun je de berekening niet maken.

Ga er maar rustig van uit dat voor ieder plaatje een request afgehandelt moet worden wat 0.1-0.2 seconden duurt. 50 fotos kost je dan thuis ook al snel een paar seconden.

[atthias]

hier zit ik op een ADSL met 3 a 400 KB max (als de rest van de straat er niet is dat ook nog) dus dat is voor mij erg prettig

[graey]

Het bespaart vooral tijd, in hoe snel een pagina functioneel in beeld is. Hoe het daarna verder gaat is inderdaad wisselend, maar dat is minder belangrijk voor google.

[Oon]

Goeie lazy loading is juist sneller. Je laadt daarmee eerst de structurele assets (dus de DOM, de stylesheet, belangrijke integraties) en daarna ga je de afbeeldingen inladen (waar dit voor ingeschakeld is).

Hele slechte en gedateerde implementaties van lazy loading beginnen pas met laden als de afbeelding al in beeld is. De ideale situatie is dat er een lagere kwaliteit versie van de afbeelding (laagste bestandsgrootte) ingeladen wordt, en daarna de lossless compressed versie. Maar zelfs als alle afbeeldingen alsnog geladen worden scheelt het flink als dit pas gebeurt nadat de rest van de pagina al in beeld is

[Saven]

Mja 't gaat ook om de requests die worden uitgevoerd. Imo is de beste optie om afbeeldingen in zijn geheel niet te laden, totdat ze ± 100/200 pixels binnen beeld vallen. En dat doet de browser met de native loading=lazy attribute niet. Die doet toch eerst voor elke afbeelding een request om het formaat te kunnen bepalen.

[Oon]

Afbeeldingen pas laden als ze in beeld zijn is IMO geen optie. Ik heb veel met klanten gewerkt die grote nieuws-achtige websites hadden waar veel afbeeldingen op stonden (beetje zoals de Tweakers homepage maar dan met een grote afbeelding voor ieder artikel) en dat was een heel gekloot om alles snel geladen te krijgen.

Uiteindelijk hebben we met wat custom JS een soort van flexibele lazy loading geschreven, waar wat jij zegt gebeurt maar dan in deze berekening het scherm 50% doorgetrokken (25% bleek toch nog storend, meer dan 50% was gelukkig niet nodig). Dat gecombineerd met een snelle CDN en lossless compressie op alle afbeeldingen, en het goed doorsturen van het juiste formaat afbeelding, zorgde ervoor dat de gebruiker het lazy loaden vrijwel nooit zag (ook niet op mobiel) en er niet honderden requests gestuurd werden op de homepagina.

Maar wanneer dat te ingewikkeld is zou ik er toch zeker voor pleiten om in ieder geval na het laden van de pagina zelf een lagere kwaliteit versie van alle afbeeldingen direct op te halen, zodat je geen lege vakjes krijgt. Zelfs al zijn dat 200-300 requests en kun je geen HTTP2 gebruiken, dan nog zou de gebruiker hier weinig van merken en praat je dan over 1-2MB aan extra bandbreedte. Dat is vergelijkbaar met wat veel grote websites nu ook al doen (nu.nl is bijvoorbeeld ongeveer 10MB, tweakers.net is ook al 5.7MB).

[Verwijderd]

Dat Lazy Loading lijkt alleen te werken met de ingebouwde Wordpress gallery.
Ik gebruik NextGen gallery op mijn site, en daarbij worden de foto's nog steeds traditioneel geladen bij het openen van een pagina.

[Verwijderd]

Nee, het zit native in de browser tegenwoordig. Gewoon loading="lazy" toevoegen aan je <img src> element. Voila.

[Gubbel]

Dit werkt overigens niet op Apple devices, dus een fatsoenlijke lazy loading zoals ze al jaren gebouwd worden heeft nog steeds de voorkeur.

[BramVroy]

Werkt momenteel inderdaad nog niet in browsers zoals Firefox mobile en (iOS) Safari.

[GertMenkel]

Apart dat Apple zo achterloopt op iets waarmee zo makkelijk performancewinst te behalen valt. Normaal zijn ze behoorlijk snel met dit soort voordeeltjes.

Dat de LTS-versie van Firefox (en Firefox for Android) hem niet supporten kan ik begrijpen want die twee lopen standaard achter (alhoewel de nieuwe Firefox preview toch al vaart begint te maken).

Gelukkig zijn er polyfills zodat je als ontwikkelaar gewoon de standaard kan gebruiken en achterlopende browsers via Javascript alsnog kan ondersteunen.

[Verwijderd]

Komt eraan.

[Verwijderd]

Precies. Zit in de technology preview 👍🏻😀

[Verwijderd]

Die tags worden automatisch gegenereerd door Wordpress en de plugin.
Enig idee hoe ik dat kan doen?

[mpol]

Je kunt een vraag plaatsen op hun support forum:
https://wordpress.org/support/plugin/nextgen-gallery/
Dat WordPress Core het ondersteunt betekent nog niet dat plugins het ook automatisch overnemen. Veel plugins die werken met afbeeldingen gaan deze periode deze vraag krijgen van gebruikers verwacht ik.

[Verwijderd]

https://web.dev/native-lazy-loading/

HIer staat het volledig uitgelegd.

[BramVroy]

Can I use linkje met browsercompatibiliteit: https://caniuse.com/#feat=loading-lazy-attr

[SkiFan]

Goede vernieuwingen. Er zijjn de afgelopen jaren té veel sites te grazen genomen door verouderde of lekke plugins, vaak terwijl de update al klaar was.

Ik besef dat het ook issues kan opleveren, maar dat lijkt me altijd nog beter dan een gehackte infrastructuur.

[Wim-Bart]

Onvoorstelbaar dat het nu pas kan, loopt wel super achter op Joomla.

[Tralapo]

Het kon altijd al wel, door een bestandje als mu-plugin te uploaden of een filter toe te voegen in functions.php. Het is absurd dat het zo lang geduurd heeft voor het eindelijk in een interface terecht kwam.

[Reactie gewijzigd door Tralapo op 26 juli 2024 11:59]

[las3r]

Ik vind het een mooie geste, zeker die automatische update. Het gaat me helpen de "simpele" plugins automatisch te laten updaten, maar het is me al meermaals voorgekomen bij het updaten van (paid) third party plugins dat er soms toch iets "anders" gebeurt dan je zou verwachten, of bijvoorbeeld ui-werk helemaal wijzigt. Op zich prima, maar maatwerk ploft op dat moment (ook al is deze op de juiste manier gemaakt).

Mooie stap!

[Gubbel]

Dat "ui-werk" wat helemaal wijzigt zou in theorie alleen in een major version moeten komen en die zitten niet in de auto-updates.

[Verwijderd]

Automatische updates op je plugins? Mooi. Totdat een plugin bouwer er iets in bouwt waardoor je automatisch mee instemt, of je site bricked omdat ze iets niet goed hebben gedaan.

[Gubbel]

Als het net als WordPress core gaat om security en minor releases zou dit in theorie geen probleem moeten zijn. Er van uit gaande dat mensen zich houden aan de versioning scheme.

't is uiteraard dubbel, je wilt updaten voor de veiligheid, alleen weet je niet wat voor code je binnenhaalt.
Dat weet je echter met het installeren van een plugin ook niet, dus in die zien is dit alsnog alleen maar goed.

Het is overigens ook al jaren mogelijk, alleen is er nu een knopje voor gebouwd.

[Gubbel]

De titel zou eigenlijk moeten zijn "WordPress 5.5 biedt gebruikersinterface om automatische updates voor plugins en thema's in te schakelen".

Deze optie zit net als de auto updates van WordPress zelf al sinds 3.7 ingebouwd, alleen moest dit voor thema's en plugins middels een filter in de code worden ingeschakeld.

[RobbyTown]

Gelukkig kon je via een omweg al automatisch updaten namelijk via directadmin en dan via installattron aangegeven naast wp zelf ook de plugins te updaten. Voordeel is dan zelfs dat er voor de update een backup word gemaakt.

[Gubbel]

Sterker nog, 2 regels code plaatsen doet exact hetzelfde als op deze knopjes klikken. De optie zit al sinds 3.7 in WordPress.

[Linksquest]

Dat is wel Nice, wilde misschien een basis bio pagina ermee maken en zo blijft hij ook up to date.