Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Drupal 7 krijgt in 2021 end-of-lifestatus

De Drupal Association kondigt aan dat vanaf november 2021 Drupal 7 niet langer ondersteund wordt. Beheerders die nog niet overgestapt zijn, wordt geadviseerd voorbereidingen te treffen om te migreren naar versie 8.

Drupal 7 is in januari 2011 uitgebracht en bereikt eind 2021 na meer dan tien jaar dus zijn levenseinde, meldt de Drupal Association. Het Drupal Security Team verstrekt vanaf dat moment ook geen beveiligingsupdates meer, hoewel commerciële partijen wellicht op gelimiteerde basis met betaalde updates komen als onderdeel van Drupal 7 Vendor Extended Support.

Omdat de ondersteuning stopt en Drupal 7 als onveilig aangemerkt kan worden vanaf eind 2021, raadt het team achter het platform aan de migratie naar Drupal 8 in te zetten, voor beheerders die dat nog niet gedaan hebben. Het team belooft verder dat de upgrade van Drupal 8 naar 9 niet zoveel hoofdbrekens gaat kosten als die van 7 naar 8.

De adoptie van Drupal 8 gaat langzaam. Er zijn volgens statistieken van Drupal zelf 315.000 sites die versie 8 draaien, tegenover 827.000 die nog versie 7 gebruiken. De eol-melding komt op een moment dat beveiligingsbedrijf Imperva waarschuwt dat een op 20 februari gedicht lek in Drupal misbruikt wordt. Aanvallers zouden speuren naar kwetsbare sites en pogen daar cryptominers aan toe te voegen. De kwetsbaarheid maakt het uitvoeren van willekeurige php-code mogelijk, maar is alleen aanwezig wanneer modules voor Drupal 8 core RESTful en json:api aanwezig zijn.

Door Olaf van Miltenburg

Nieuwscoördinator

26-02-2019 • 13:11

73 Linkedin Google+

Submitter: InfoTracer

Reacties (73)

Wijzig sortering
Niet alleen Drupal 7 (D7), maar ook Drupal 8 (D8) zal dan end-of-life zijn (https://www.drupal.org/blog/drupal-7-8-and-9). D8 zal dan end-of-life zijn omdat Symfony 3 (waar D8 op is gebouwd) dan end-of-life is. Voor de gebruikers van D8 willen de ontwikkelaars minimaal een jaar voor die termijn een nieuwe versie beschikbaar hebben, namelijk Drupal 9 (D9). Normaal gezien is de ondersteuning bij Drupal beperkt tot 2 versies (momenteel dus D7 en D8, zodra D9 uitkomt zou normaal de ondersteuning voor D7 onmiddellijk vervallen). We krijgen echter een jaar extra om van D7 naar D8 te gaan, en overstap van D8 naar D9 zou zeer makkelijk moeten zijn. Al met al ben ik zeer tevreden over de geboden service (al moet ik dus wel eens aan de gang met de diverse D7 sites die ik nog heb draaien).
D8 zal dan end-of-life zijn omdat Symfony 3 (waar D8 op is gebouwd) dan end-of-life is.

Dit is een foute opvatting. Drupal 8 is gebouwd op Symfony componenten. Het klopt inderdaad dat de ondersteuning van de componenten van versie 3.4 (Huidige LTS versie van Symfony) gestopt wordt.
Dit is geen opvatting, dit is wat Dries op de blog heeft vermeld.
Our biggest dependency in Drupal 8 is Symfony 3, and according to Symfony's roadmap, Symfony 3 has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. To keep your Drupal sites secure, Drupal must adopt Symfony 4 or Symfony 5 before Symfony 3 goes end-of-life. A major Symfony upgrade will require us to release Drupal 9 (we don't want to fork Symfony 3 and have to backport Symfony 4 or Symfony 5 bug fixes). This means we have to end-of-life Drupal 8 no later than November 2021.
Klopt voor het grootste deel wat hij zegt, maar als je gaat kijken naar https://symfony.com/projects/drupal en naar https://symfony.com/components, dan zie je dat Drupal nog maar amper een vierde gebruikt van de componenten die binnen het Symfony framework beschikbaar zijn.

Ik wil maar zeggen dat Drupal 8 niet op Symfony gebouwd is, maar wel op componenten van Symfony, die inderdaad altijd mee updaten/upgraden wanneer symfony/symfony package zelf wordt geüpdate/geüpgrade
Ik heb Dries hier al jaren geleden (rond 2008) voor gewaarschuwd.
Gebruik maken van frameworks is leuk maar schept een enorme afhankelijkheid.
En als je eenmaal een framework gebruikt dan is dit als een 'huwelijk', je komt er heel moeilijk vanaf.
Interessant. Sinds 2007 heb ik met veel succes Drupal gebruikt (vanaf Drupal 5). Drupal 6 was waarschijnlijk m'n favoriete versie. In Drupal 7 werd Drupal Commerce naar mijn smaak onnodig ingewikkeld. Drupal 8 werd voor mij echter totaal onwerkbaar: Alsof álles in Drupal heel moeilijk moet zijn. Gebrek aan backwards compatibility is daarmee vergeleken een klein probleem, maar wél echt rete-irritant: Ik heb zat klanten met eenvoudige sites die zelden bijgewerkt hoeven te worden en prima nog jaren meekunnen - Alleen dat kan niet met Drupal, en updaten is niet reëel.

Ik heb er lang over nagedacht of ik écht wil overstappen van Drupal naar iets anders (WordPress): http://wiki.devliegendebr...rkbaar.3F_.28Aug._2017.29

Ik ben erg blij dat ik dat heb gedaan. Ik kan me moeilijk voorstellen dat er nog een markt is voor Drupal. In Google Trends kun je zien dat de populariteit flink aan het afnemen is.

P.s.: Dank voor de postings hieronder! Verfrissend om te zien dat anderen hele andere ervaringen hebben!

[Reactie gewijzigd door strompf op 26 februari 2019 20:32]

Wat ik altijd een verademing heb gevonden is dat je met fields en vroeger CCK een redelijk breed-ondersteunde manier had om verschillende soorten content-types te hebben.

Bij Joomla!, in elk geval in de tijd dat ik er mee werkte, was alles gewoon een artikel met een body-veld en dat was het. Je had wel third-party-modules, maar dat waren vaak draconische programmeersels die weer volledig op hun eigen manier werkten, en vaak ook slecht werkten met andere modules. Bij het legoblokken-systeem van Drupal waren modules veel meer geïntegreerd met elkaar en klikte je als sitebuilder zo een receptenwebsite bij elkaar, waarbij je de structuur en velden gestructureerd kon instellingen zonder houtje touwtje of hacky workarounds.
Totdat je ziet hoe CCK onder water werkt.
Dan springen de tranen in je ogen.
Database normalisatie daar kunnen de makers van CCK nog wat van leren |:( |:( |:(
Tja dat is altijd een compromis vanwege het dynamische karakter. Men kan met 1 klik dingen ineens een veld multi-input laten geven, terwijl dat achter de schermen een heel andere architectuur vereist.
Ik begrijp je antwoord maar denk toch dat ontwikkelaars niet altijd voor de snelle/simpele oplossing moeten kiezen maar zich soms even wat langer achter de oren moeten krabben voordat ze gaan coden.
Het is een andere opzet, maar wel met flinke leercurve, vooral als je OOP en/of symfony en/of twig niet goed kent. Met een goeie dumper (ik raad symfony/var-dumper aan) zie je snel alle vars en methods van functies. Kwestie van doorbijten (verzin desnoods een inspirerend project voor jezelf of port een d7 naar 8. Je zult vast modules missen, maar tegelijkertijd biedt dat veel ruimte om zelf de handen uit de mouwen steken en kan je de community op een mooie module trakteren.

Ik werk professioneel zowel met 7 als 8, en ben helemaal in love met het configuratiesysteem van Drupal 8 en alle handigheden die de classes en methods bieden. Met minder coderegels en groter deploymentgemak wordt het werk makkelijker en leuker.
Config export is, wat mij betreft, de beste verbetering die Drupal in lange tijd gehad heeft!
Als het zo makkelijk is, dan betaal ik mee aan de port van de date en calendar modules door jou van D7 -> D8.
Zo te lezen ben je in een paar dagen wel gereed.
Ik sta altijd open voor porten van modules als er budget voor is, je mag me altijd contacteren indien interesse: https://www.drupal.org/user/462700/
Ik heb een totaal tegenovergestelde ervaring. Drupal 6 heb ik beperkt ervaring mee, maar vond ik een hel om robuuste code voor te schrijven.

Drupal 7 was al een hele verbetering maar het ontbrak goede deployment manieren waardoor we de helft van de tijd installatiescripts moesten maken om sites bij te werken.

We zijn nu sinds een goed jaar over op Drupal 8 en dat is echt hemels. De integratie met Symfony, Composer en de config export maken development met meerdere personen en deployment echt een breeze. Vertalingen en entity references zijn veel verbeterd. Ook twig vind ik als grotendeels frontend developer erg leuk werken. Er zijn nog maar weinig D7 modules die niet over zijn op D8.

Dat Drupal niet het beste platform is voor kleine sites leek me al wel langer duidelijk. Maar daar richten ze zich dan ook in mindere mate op.
Ik heb zat klanten met eenvoudige sites die zelden bijgewerkt hoeven te worden en prima nog jaren meekunnen - Alleen dat kan niet met Drupal, en updaten is niet reëel.

Ik heb er lang over nagedacht of ik écht wil overstappen van Drupal naar iets anders (WordPress): http://wiki.devliegendebr...rkbaar.3F_.28Aug._2017.29
Dan gebruik je de verkeerde "tool".

Als het simpele websites zijn waar nauwelijks interactie plaats vindt, kun je kijken naar static website generators. Want WordPress zal ook te krachtig zijn voor dat soort sites.
Ik zie tal van mensen klagen dat de modules nog niet zijn geupgradet, maar eigenlijk is dat natuurlijk niet de verantwoordelijkheid van Drupal. Ze hebben al die functionaliteit juist in modules gestopt omdat het geen onderdeel van het kern-product is en ze het niet ondersteunen. Als je er dan toch voor kiest om die modules te gebruiken dan is het je eigen verantwoordelijkheid.
En eigenlijk geldt dat voor het hele product.

De developers van Drupal hebben er immers geen last van dat jij nog een oude versie gebruikt.
De developers van die modules ook niet.
Op het moment dat je zo'n stuk software in gebruik neemt aanvaard je er verantwoordelijk voor.

Ik breng het nogal lomp omdat deze denkfout aan de lopende band gemaakt wordt. Software is als een tuin, het kan niet zonder onderhoud. Je kan zo'n systeem niet eenmalig bouwen en dan verwachten dat het zich voortaan zelf regelt. De valkuil bij gratis en vrije software is dat gebruikers verwachten dat ook de ondersteuning gratis is. Zo werkt het natuurlijk niet, onderhoud en ondersteuning zijn 95% van de kosten, dat is een van de redenen dat er zo veel gratis software te vinden is.

Je hoeft niet te betalen voor ondersteuning als je dat zelf kan, maar als je zelf niet de kennis of de tijd hebt dan zul je daar iemand voor moeten betalen. Net als bij je tuin. En net als bij je tuin kun je bij het inrichten maar beter nadenken over onderhoud en upgrades, want die zijn altijd nodig. Als je daar niet over nadenkt en gewoon maar wat plantjes van de markt haalt dan eindig je waarschijnlijk met een lelijk oerwoud.
Je kan het ook anders bekijken, namelijk dat de modules gemaakt voor versie 6 ook moeten werken in hogere versies. Backwards compatible. Dat er mogelijkheden en opties in een nieuwe versie bijkomen is prima, maar bij de release van een nieuwe versie verwachten dat alle modules dan ook maar even door alle verschillende developers moeten worden geupdate is gewoon weg vragen om problemen bij je gebruikers.

Ik denk niet dat bijvoorbeeld word nog gebruikt zou worden als je bij nieuwe versies opeens je oude documenten opnieuw moet opmaken omdat een lettertype niet meer Bold gemaakt kan worden (erg simpel voorbeeld).
Ik vind de tuin vergelijking niet helemaal opgaan. Bij een tuin kan je plantjes planten en mits je alle randzaken goed op orde hebt (zoals bijv zuurgraad, de juiste plek enz) zijn de plantjes zelf onderhoudend.

Het lastige aan de software wereld is bijv:

1. Drupal is voor stukjes gebaseerd op
2. Symphony 3, beide weer op
3. PHP, wat geschreven is in C & C++ en gebruik kan maken van
4. Costum extensies die allemaal weer beginnen bij stap 1 :p

Het is alsof je een appelboom hebt wat is opgebouwd uit stukjes peren bomen die weer opgebouwd zijn uit stukjes walnotenboom die weer aangevuld is met kleine stukjes appel, peren, bananen, walnoten en mandarijnen bomen.

Helemaal niet erg mits je hiervan bewust bent alleen het word pas ingewikkeld als ergens stukjes niet meer worden onderhouden of wanneer iemand zonder kennis ergens een stukje van het geheel niet goed afsteld op de locatie waar die appelboom (waar het mee begon) moet gaan leven :p

Gelukkig hebben we tuin mannen / vrouwen (zoals CIS https://en.m.wikipedia.org/wiki/Center_for_Internet_Security ) die dit alles net iets makkelijker maken mja hoeveel mensen hebben nu echt een tuinman? Zelfs als het gratis is doen veel eigenwijze mensen het liever zelf of gewoon helemaal niet

[Reactie gewijzigd door Mellow Jack op 26 februari 2019 22:34]

Zolang de API niet al te veel veranderd is het geen probleem, maar de Drupal API schijnt bij elke versie nogal te moeten varanderen, en dat is welzeker ook een verantwoordelijkheid van de core-developers.
Wat ondergesneeuwd raakt is het feit, dat Drupal 8 dan óók end of life wordt.
https://www.drupal.org/blog/drupal-7-8-and-9
Dus upgraden naar D9
Het team belooft verder dat de upgrade van Drupal 8 naar 9 niet zoveel hoofdbrekens gaat kosten als die van 7 naar 8.
Klinkt bekend. ;)
Tijdens de doorontwikkeling van Drupal 8 kunnen sommige functies deprecated worden, als er een vervanging voor is geschreven of een betere oplossing. De overgang van Drupal 8.latest naar 9.0 zal alleen inhouden dat al deze deprecated functies verwijderd zullen worden.

In principe zou je dus tijdens het onderhoud van de site eventueel maatwerk dat gebruik maakt van een deprecated functie, al om kunnen zetten naar de nieuwe, waardoor een upgrade naar 9 zonder problemen gaat lukken.

Zie ook: https://dri.es/plan-for-drupal-9
Zullen ze toch meer D7 modulen geschikt voor D8 moeten maken.
De enige reden, dat ik met diverse sites nog niet ben overgegaan.

De belangrijkste voor mij is de date module.

[Reactie gewijzigd door Euronitwit op 26 februari 2019 13:17]

Date zoals je het in D7 hebt zit niet in core.
In core zit slechts een slap aftreksel van de sterke D7 module.Het kind wordt met het waswater weggegooid, terwijl het zo'n sterke module was geworden t.o.v. de D6 versie

Repeating day zit er o.a. nog steeds niet in.
https://drupal.stackexcha...ave-recurring-date-events
Calendar zit er nog niet in https://www.drupal.org/pr...ib_tracker/issues/2578231
En dan heb ik het nog geenzins over de andere modulen, die daar van afhankelijk zijn.
Wij gebruiken zowel calendar als date_recur op verschillende projecten.

Als we bugs tegenkomen, contributen we gewoon fixes. Als iedereen zo werkt, komen we er wel ;)
Als o.a. hostingprovider lopen wij er ook telkens tegen aan dat klanten dingen gebruiken waar geen support op zit. Modules die niet PHP7 compatible zijn en vervolgens verwijzen ze naar module maker.... dit geldt niet alleen voor Drupal maar ook andere CMS'en zoals Joomla en Wordpress.

Maar ergens moeten wij een lijn te trekken, want PHP > 7 zijn allemaal EOL.
Zelfs 7.0 zelf is EOL en 7.1 alleen nog security fixes
http://php.net/supported-versions.php
Als je Debian 9 gebruikt, worden security fixes voor PHP 7.0 nog gebackported.
Mee eens.
Wij hebben vele sites op Drupal 7 draaien omdat de modules nog niet of beperkt beschikbaar zijn voor Drupal8.

Ook veel zelfgebouwde modules zullen toch aangepast moeten worden.
14.266 - D7 modules tegen 6.783 - D8 modules
https://www.drupal.org/project/project_module/index

20 date gerelateerde D8 modulen waarvan verschillende NIET gesteund worden vanwege de veiligheid.
Andere zijn zelfs nog niet uit de alpha status.
En dat voor een core module na ruim 4 jaar.
Goed punt....een aantal elementaire modules (locatie, maps) werkt nog steeds niet goed in Drupal8 en heeft nog een aantal blockers.
Zullen ze toch meer D7 modulen geschikt voor D8 moeten maken.
Het is open source; ga je gang! :Y)
Ik kan niet programmeren.
Ik heb verschillende module updates van D 6 -> D 7 betaald.
Welke lasten niet willen als ik meebetaal / heb betaald? 8)7
Je hebt ooit betaald voor een of meerdere ports van een module van Drupal 6 (15+jaar oud) naar Drupal 7 (bijna 10 jaar oud) systeem. En dan wil je over naar een nieuwere versie zonder te investeren erin?
Dan vrees ik dat je moet wachten tot andere personen en bedrijven wel tijd en geld investeren en zorgen dat het een betere module wordt.

Dit is nou eenmaal hoe open source communities werken.
De D8 port van de module, die ik nodig heb zullen zeker door mij betaald worden.
Echter de date en calendar modulen, daar betaal ik niet aan mee.
Als ze vinden, dat die in core thuishoren, dan moeten ze ook zorgen, dat het werkt.
Je hebt betaald voor de development in D7. Dus, nee je hebt niet mee betaald voor de development van de opvolger. Overigens, dikke kans dat het niet aan Drupal ligt maar aan Symphony, wat redelijk anders is tussen hun major versies
Symfony werkt met het BC-principe dus dit zou in principe niet kunnen.
Ook met het BC-principe is er onderhoud nodig. Wat in de huidige major versie deprecated is wordt in de volgende major versie verwijderd. Semver vereist dat je deprecations opvolgt en oplost.
De lasten zijn het geld afdragen in deze. Als hij alles zelf moet forken, gaat ie hen geen geld betalen.
Wellicht handig om ook te vermelden wat drupal is.
Van wikipedia.
Drupal is een opensource-contentmanagementsysteem (CMS) en contentmanagementframework (CMF), ontwikkeld in de programmeertaal PHP en uitgebracht onder de GPL. Drupal wordt gebruikt om websites en weblogs te beheren.
Voor mensen die zich nu afvragen wat een CMS is
Een content-beheersysteem of contentmanagementsysteem is een softwaretoepassing, meestal een webapplicatie, die het mogelijk maakt dat mensen eenvoudig, zonder veel technische kennis, documenten en gegevens op internet kunnen publiceren
In het kort, het vormt de basis voor een aanzienlijk aantal websites op het internet.
Diegenen die het gebruiken weten al wat het is, en voor diegenen die het niet weten zijn er zoekmachines zoals Bing, Google of Yahoo.
Het is prima op te zoeken, maar het is (ook bij Tweakers.net) gebruikelijk om even kort te melden wat iets is, zeker als het geen gemeengoed is. In een artikel over bijvoorbeeld The Outer Worlds (26-2-2019, 10:05u) staat "...de in december vorig jaar aangekondigde ruimte-rpg The Outer Worlds..."

Hier had bijvoorbeeld begonnen kunnen worden met iets als "... het in januari 2011 uitgebrachte open source CMS systeem Drupal 7..."

[Reactie gewijzigd door Tuktop op 26 februari 2019 13:31]

Euh... wat is een rpg?
Ik heb lang niet geweten dat Yahoo een zoekmachine was, totdat ik bij Microsoft (kende BING ook niet) wilde adverteren.... en ze dat bij Yahoo hadden uitbesteed.

Maar in andere landen is Yahoo net zo groot als Google hier. (zeker wat email aangaat)
Dus je wilt zeggen dat het toevoegen van 3 woorden in de introductietekst te veel gevraagd is voor een artikel met een onderwerp waar 80% van de bezoekers van Tweakers waarschijnlijk nog nooit van heeft gehoord? Als ik alles nog een keer moet gaan googlen dan kan ik net zo goed het artikel ergens anders lezen. Ieder ander artikel beschrijft het onderwerp in ten minste een paar woorden. Het bovenstaande artikel kan zowel over een besturingssysteem voor auto's als een kassasysteem voor de Albert Heijn gaan. Context is wenselijk. Een artikel zonder context is een slecht artikel.
Welke drie woorden kent 80% niet?

"Drupal 7" = CMS / Framework versie 7 is 1 van de drie grotere naast WP en Joomla

" krijgt in 2021" = datum aanduiding?

"end-of-life-status" = EoL wat al sinds vorige eeuw aanduiding is dat een software/hardware product niet meer onderhouden/leverbaar zal zijn.
Ik heb het niet over het niet kennen van 3 woorden, ik heb het over het niet kennen van het platform en dat je dit met 3 woorden in de introductietekst kan verduidelijken.
Sure, maar bij een artikel over de iphone x gaat staat ook dat het over een telefoon gaat. Bij een artikel over autonoom rijden staat ook waar het over gaat. In dit geval staat er enkel dat een versie van iets end of life gaat. Ik wil op zijn minst kunnen weten waar het over gaat om vervolgens te kunnen bepalen of het interessant is voor mij of wellicht iets nieuws te leren.
Ik denk dat 80% van de bezoekers van Tweakers wel meteen wisten wat Drupal is (en anders weten ze het nu).

Zou wel grappig zijn als Tweakers eens een woorden enquête zou doen, waarbij binnen bepaalde tijd een enquête moet worden voltooid met veel voorkomende termen.

Meteen een spiegel voor ons allen. (misschien heb je wel een punt en wist niemand wat Drupal was)
80%? Dit is niet telegraaf.nl, dit is tweakers.net.
Klopt, bij telegraaf.nl zal dit percentage verder stijgen tot zo'n 98% als ik een gokje mag wagen. Sterker nog, ik gok dat de meeste van de gebruikers van het platform drupal niet eens kent omdat wanneer het in een bedrijfsoplossing wordt geïmplementeerd je de naam vaak nergens meer terug ziet.
Goh, misschien om er achter te komen wat drupal is? Het feit dat er een artikel aan wordt gewijd impliceert dat het relevant is voor een grote doelgroep, vervolgens valt nergens te zien wat het is en bereik het artikel niet zijn doel, het informeren van een grote doelgroep, aangezien ondanks dat veel mensen het dagelijks gebruiken ze geen idee hebben wat drupal is.
Wat is het doel van een dergelijk artikel? Informeren
Wat doet dit artikel niet op de juiste manier? Informeren
Iets met journalistiek en zo.
Dit is een artikel op Tweakers.net, geen Nu.nl o.i.d. Men mag er vanuitgaan (en doet dat ook) dat de gemiddelde Tweakers.net-lezer weet wat Drupal is. Voor de enkeling die dat niet weet is er dan altijd nog Google.

[Reactie gewijzigd door PDZ op 26 februari 2019 13:51]

assumption is the mother of all f ups.
Ondanks dat het voor jou gemeengoed is omdat je er wellicht iedere dag mee in aanraking komt kan ik je verzekeren dat dat niet het geval is voor de meeste tweakers. Tweakers wordt gelezen door een ontzettend breed publiek, niet alleen die hard nerds. En er zijn zelfs zat die hard nerds die geen idee hebben wat drupal is. Als ik vervolgens om context te krijgen voor een artikel moet gaan googlen dan is er iets mis met het artikel.

Lees de eerste zin van het onderstaande artikel, dan snap je wellicht wat ik bedoel;
nieuws: Aanvallers misbruiken kritiek Drupal-lek kort na uitkomen patch
Leuke zin waar je mee begint, aangezien je verderop in je reaktie aanneemt dat Drupal voor mij gemeengoed is. Ik heb er letterlijk nog nooit in mijn leven mee gewerkt.

Verder begrijp ik je punt wel hoor, maar ik heb zelf een beetje mijn twijfels waar je dan de grens legt. Bij elk artikel zou je wel uit kunnen leggen wat iets is, maar dat lijkt me ook weer overbodig.
Dat was het punt, maargoed het is vrij normaal om een artikel te beginnen met een korte omschrijving van het onderwerp. Dit kan met een paar wooren en maakt het artikel voor iedereen leesbaar. Zelfs een artikel over een Windows 10 feature kan je beginnen met "De nieuwste feature voor het computerbesturingssysteem van Microsoft is.... etc".
Heel ingewikkeld is het niet.
Het kan evengoed een server OS, softwarepakket voor netwerkhardware of grafische interface voor een website zijn. Nergens valt uit op te maken dat het om een CMS systeem gaat.
Als ik aan sites draaien denk dan denk ik aan de server waar het op draait, maargoed ik heb het over een introductie aan het begin van de tekst waar duidelijk wordt vermeld waar het over gaat ipv een hint halverwegen de tekst die alsnog niet uitlegt wat het bedrijf doet.
Alles is te hacken. SQL injectie gebeurt juist veel meer bij dit soort ouderwetse code.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Games

'14 '15 '16 '17 2018

Tweakers vormt samen met Tweakers Elect, Hardware Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True