Moet je Drupal7 gaan gebruiken voor een nieuwe Drupalsite?

Maandag, 27 September 2010

In een recente mailcorrespondentie voorzag ik iemand van wat advies over Drupal 7.
Drupal 7 is de Drupal die binnenkort gereleased zal worden als opvolger van Drupal 6. Drupal6 is daarmee niet ten einde, mogelijk blijft deze nog jaren onderhouden. Drupal 5 komt daarmee wél te vervallen.

De mail vroeg:

Ik wil eigenlijk gaan beginnen met D7 aangezien deze er nu bijna is en het project sowieso nog wel een 4-tal maanden zal duren.
Een medewerker van Dries bij Acquia duwde ons ook in deze richting voor onze community site.

En ik antwoordde:

Eerlijkgezegd geloof ik hier voor geen meter in. Tenzij je concrete voorbeelden boven water kunt krijgen waar Drupal7 nu al beter is dan Drupal6. Ik zie die voor jullie project nog niet. Je zult hoe dan ook een technisch ontwerp (naar een functioneel ontwerp) moeten opzetten. Als in dat technisch-ontwerp grote problemen boven water komen, die met Drupal7 opgelost zouden worden, is dat natuurlijk een goede optie.
Maar als dat niet zo is, is Drupal7 altijd een nadeel:

  • Onbekend (reken op maanden, mogelijk een jaar na release voordat er net zoveel experts en developers voor zijn als voor 6).
  • Onbekend (marketeers roepen natuurlijk dat het getest en klaar is, maar dat moet eerst nog bewezen worden).
  • Onaf, third party modules worden grotendeels al vooraf klaargemaakt. Maar wat ik daarvan gezien heb, valt a) het aantal modules dat voor 7 klaat is tegen, maar is vooral b) de kwaliteit van die ports erg (erg) slecht vaak. Verwacht dat in het eerste half jaar van Drupal7 de helft van die modules vervangen wordt door alternatieven.
  • Als je zo vroeg op de trein springt is dat uiteraard niet te voorkomen in geval drupal 7 nieuwe features heeft die in 6 niet te krijgen zijn, maar heel onverstandig, omdat je écht in de voorhoede meedraaft, en dus veel zelf moet uitvinden (in plaats van gebaande paden te volgen) en daarmee vaak doodlopende paden bewandelt, met onvermijdelijke pijnlijke migraties voor de boeg.

    Mijn advies, kortom was, om voorlopig nog niets met Drupal 7 te gaan doen. Het betreft hier een groot project (4 maanden ontwikkeling) en dus niet De Blog Van Mien. Voor een klein, goed te overzien project is Drupal 7 precies net zo goed als Drupal 6. En zijn kleine voordelen als "Maar Drupal 7 heeft een heel coole interface" geldige argumenten om ervoor te kiezen. Maar voor ieder groter project moet je je richten op de technische eisen en wensen. En daarvan heeft Drupal 7 mogelijk enkele kant-en-klaar, terwijl 6 die niet heeft. Maar andersom is de kans even zo groot, of groter, dat vor Drupal6 daar al een goed getestte en uitgewerkte oplossing is, terwijl in de wereld van Drupal 7 nog niets uitgewerkt is voor dat specifieke probleem.


Tags: Drupal,

Je bemerkingen zijn inderdaad

Je bemerkingen zijn inderdaad helemaal correct.
Maar ... (die hoort er altijd bij)

We zitten momenteel in start/pitch fase voor een 3-tal grotere projecten (4a6 maand) en daar is niet de functionaliteit van D7 het argument om naar D7 te gaan, maar wel de totale Lifetime van het project.
Dit zijn sites die zo'n 4a6 jaar in de lucht moeten blijven en zodanig dus in problemen zullen komen kwa maintainance.
Als zo'n site nu nog in D6 wordt opgezet dan ben je er zeker van dat je over 2a3 jaar een Major upgrade aan je broek hebt. Met de bijhorende (volgen mij TE) grote meerkost van zo'n major upgrade.
2 opties liggen er dus volgens mij open:
1) Starten met een D6 site die functioneel zo dicht mogelijk bij contrib modules ligt, en die relatief goedkoop kan ge-upgrade worden naar D7 om dan te Hard (custom) Stuff te integreren.
2) Onmiddellijk starten met D7 en dan de risico's lopen (extra budget van 20% ??) om tijdens het project zelf modules te moeten porten etc..

Vandaar .. voor de functionaliteit moet je het zeker niet doen, maar naar maintainance van lang lopend project wordt het vraagstuk wat complexer.

my 2 euro-cents

Maintainance... Hmmm. Denk je

Maintainance... Hmmm.
Denk je werkelijk dat die (abominabel!) slecht, in alle haast geportte Drupal7 contribs stand gaan houden?
Als ik naar Drupal6 kijk is mijn antwoord: nee!

Wanneer je dus nu begint met een Drupal 7 site, met daarin 80 contrib modules, kan ik welhaast garanderen dat een twintigtal daaruit dood gaan. Niet ondenkbaar is dat dit zelfs in de veertig of meer kunnen worden.

Drupal 7 doet veel zaken héél anders. Dat is goed.
Maar dat betekent automatisch dat modules zaken óók heel anders moeten gaan doen. Ergo, met geheel incompatible, nieuwe versies komen, of vervangen door alternatieven die beter passen.

Voorbeeld: http://drupal.org/project/content_profile

Deze komt waarschijnlijk in geheel niet beschikbaar voor Drupal 7 (alternatief is er overigens nog niet, echt). Maar deze module is vrijwel essentiëel voor een community-site met uitgebreidere profielen. G aje voor profile2? Of voor een van de ander (alpha) modules? Bak je zelf iets in elkaar?

Hoe dan ook, de kans dat je ter zijner tijd, als een de-facto-standaard zich heeft opgewerkt, over een, 1,5 jaar, een vieze, moeilijke en smerige migratie moet gaan doen.

In Drupal6 weet je precies waar je aan toe bent: een module die (redelijk) werkt. Die wat randvoorwaarden heeft (ook bekend) en die waarschijnlijk ooit een door de commmunity gebouwde migratie naar de dan de-facto Drupal7 oplossing heeft. Of niet. In dat geval heb je gegokt maar niet minder verloren dan je in de Drupal7 route (zeker) verloren zou zijn.

Ofwel: Drupal6 bied zekerheid. Ook qua maintainance. Drupal 7 bied een theoretisch maintainance voordeel, waar in de praktijk nú al veel op af te dingen is.

Edit: "ergo..." argument verduidelijkt.

Ik deel de mening van Roel.

Ik deel de mening van Roel. Als je nu start met Drupal 6 start je met een eindereeksproduct. Eindereeksproducten hebben alle nodige opties van vandaag en zijn stabiel, maar ook snel verouderd.
Als ontwikkelaar is nu voor Drupal 6 kiezen een makkelijke keuze, alles is er en werkt zoals je verwacht, maar het is ook een beetje kortzichtige keuze omdat je dan toch behoorlijk snel een verouderd product mag onderhouden. Ik weet niet hoe leuk jij het nu vindt om aan een Drupal 5 site nog te werken als je weet dat veel van de dingen die je moet doen in Drupal 6 veel makkelijker of beter kunnen.

Het is uiteraard nog steeds een moeilijke beslissing. Te vroeg starten met Drupal 7 kan er inderdaad toe leiden dat je in het begin wat meer met bugs en problemen zult te maken hebben, maar op langere termijn wel met een betere installatie zult zitten. De klanten gewoon open informeren over die keuze en bepaalde kleine afwerkingsmodules die nog niet klaar zijn en waar wellicht een betere oplossing voor komt in een latere fase plannen kan ook een oplossing zijn.

Ik hoop in elk geval wat grotere sites al in het eerste kwartaal van 2011 te kunnen opleveren. 2010 kan nog wat vroeg zijn, maar een jaar of langer wachten zoals jij voorstelt lijkt met echt te veel.

Trouwens de eindsprint voor Drupal 7 lijkt nu toch ingezet, zie http://buytaert.net/drupal-7-lets-get-it-done.

Wij wachten wel nog op de beta om effectief te starten in Drupal 7. In een tussenfase zouden we eventueel starten in Drupal 6 met enkel core en cck, waarin inhoudstypes en content al kan gestopt worden, waarna we een eenvoudige core upgrade doen naar Drupal 7 om vervolgens de andere modules te implementeren.

Je voorbeeld van content profile is trouwens niet zo goed gekozen, vermits dit net één van de functionaliteiten is die nu bij Drupal 7 in core zit, op admin/config/people/accounts/fields kun je bij een basisinstallatie gewoon velden toevoegen aan de user zelf, zonder enige extra module en zonder profile. Dus geen problemen om een community site te maken.

Hans, je stelt dat Te vroeg

Hans, je stelt dat

Te vroeg starten met Drupal 7 kan er inderdaad toe leiden dat je in het begin wat meer met bugs en problemen zult te maken hebben, maar op langere termijn wel met een betere installatie zult zitten.

Mijn punt is dat dit laatste juist niet waar is, in de praktijk.

Als je met nieuwe software bezig gaat, heb je niet alleen maar te maken met die "meer bugs".

Je hebt, eerst en vooral met "niet uitgekristaliseerde zaken" van doen. Dat wordt heel vaak over het hoofd gezien.

Ik werk regelmatig nog met Drupal 5 (never fix something that ain't broken) juist omdat de klant daar dingen mee kan die in Drupal6 weer veel effort en porting en migraties zouden kosten om ook daar te kunnen.

Ik werk ook aan diverse heel verouderde sites, waarvan ik de laatste weken een heb proberen te upgraden, uit het beginjaar van Drupal6. Ik ben verbaasd over de hoeveelheid modules die "dood" zijn, die ooit geport waren vanuit 5, maar nooit écht uitontwikkeld. Sommigen omdat er gewoon betere Drupal6 alternatieven waren, sommigen omdat de auteur geen zin meer had.

Zit je daar mooi, met je jaren aan cumulatieve Data die nooit meer makkelijk gemigreerd kan worden naar de "Drupal default Way To Do Stuff anno 2010".

Om mijn voorbeeld te verduidelijken: je kunt wel degelijk met fields profielen maken in Drupal.
Alleen heeft 1) nog niemand daar enorme sites mee gebouwd, 2) kent niemand de échte rariteiten, randvoorwaarden en details van dat systeem (offerte?) 3) weet nog niemand hoe dit zich gaat uitkristaliseren. Hoe gaat dit op logintobogan aansluiten? wat wordt de default om meerdere profielpagina's te maken? Wat worden technieken om velden af te schermen? Hoe gaat dit passen in de -tig modules die nu rondom content_profile opgericht zijn?

Pas als zulke zaken duidelijk zijn, daar modules bijgebouwd zijn die ook "The New Way To Do This In Drupal anno 2012" blijken, ben je veilig.

Pas dan weet je dat je niet een of andere "flexinode" (sic) hebt waar al je jaren aan data ingaat en waar je nooit meer (makkelijk) uit kunt migreren.

Hans (en een beetje

Hans (en een beetje off-topic) > Volgens mij is dat niet helemaal wat Ber bedoeld. De profile module is in D7 inderdaad niet helemaal gemigreerd naar de nieuwe field API. Wil je dus profiles als nodes willen benaderen dan zal je idd een module moeten gebruiken.

Verder ben ik het helemaal met Ber eens. Wij zullen komend half jaar hoogstwaarschijnlijk geen grote projecten aanpakken in D7. Maar ongetwijfeld wel kleinere (denk aan het migreren van onze eigen site)om ervaring op te doen.

Wil je dus profiles als nodes

Wil je dus profiles als nodes willen benaderen dan zal je idd een module moeten gebruiken.

Dat is precies wat ik bedoel. In mijn artikel zélf heb ik express geen voorbeelden genoemd om dit soort "jamaar daar en daarmee kun je dit wel oplossen"-argumenten niet in de discussie te vermengen.

Punt is, je zult een heleboel concepten tegenkomen die in Drupal 7 nog lang niet uitgekristaliseerd zijn. En dus de nodige problemen gaan opleveren.

Nieuw commentaar posten

De inhoud van dit veld is privé en zal niet publiekelijk getoond worden.
  • Lijnen en paragrafen worden automatisch opgesplitst.

Meer informatie over formaatmogelijkheden