Uitbreidingen

Waarom veel SuiteCRM-plug-ins updates moeilijker maken

SuiteCRM dankt een groot deel van zijn verspreiding aan uitbreidbaarheid. Juist die kracht wordt in lang gebruikte installaties een beheerrisico: niet omdat uitbreidingen op zichzelf problematisch zijn, maar omdat de som van de ingrepen in dezelfde kern moeilijk te testen en upgraden wordt. Dit artikel beschrijft het mechanisme, typische patronen en een werkwijze voor beheerders en IT-management – zonder afzonderlijke communityprojecten algemeen af te waarderen.

1. Wat ‘plug-inchaos’ hier betekent – en wat niet

‘Plug-inchaos’ is geen moreel oordeel en geen oproep om de uitbreidingswinkel te vermijden. Bedoeld wordt een toestand van de installatie:

• Er zijn veel pakketten geïnstalleerd, maar slechts een deel is inhoudelijk nog actief in het proces.
• Meerdere uitbreidingen raken hetzelfde gebied (bijvoorbeeld e-mail, lay-outs, workflows, bestanden).
• Maatwerkcode en pakketten zijn vermengd; niemand kan binnen een uur zeggen wat bij een upgrade ‘kritiek’ is.
• Staging bestaat alleen in theorie – of staginggegevens zijn zo verouderd dat tests schijnzekerheid geven.

Het tegenovergestelde is niet ‘nul uitbreidingen’, maar duidelijke verantwoordelijkheid en een beheersbare testmatrix.

2. Waarom upgrades op de combinatie vastlopen

Een SuiteCRM-upgrade (patch of hoofdversie) verandert kerngedrag, interfacelagen, afhankelijkheden en vaak PHP-eisen. Elke uitbreiding die daarop aansluit, moet bij de nieuwe combinatie passen. De complexiteit groeit niet lineair:

• Twee niet-kritieke rapportage-uitbreidingen zijn vaak niet-kritiek.
• Twee uitbreidingen die beide de e-mailverzending of hetzelfde logic-hookpunt gebruiken, veroorzaken wisselwerkingen.
• Tien pakketten plus projectspecifieke hooks leveren een testgebied op dat geen team zomaar kan afdekken.

Daarom is de uitspraak ‘bij ons was de upgrade problematisch door plug-ins’ meestal onnauwkeurig. Preciezer: De upgrade was problematisch omdat de installatie vóór de upgrade niet upgradegeschikt was gemodelleerd en getest.

Factor	Laag risico (tendens)	Hoger risico (tendens)
Ingreepdiepte	Weergave, rapportages, eenvoudige velden	Hooks, schema, scheduler, authenticatie, e-mail, opslag
Aantal actieve leveranciers	1–2 met releaseonderhoud	Veel, deels zonder SuiteCRM 8-release
Maatwerkcode	Gedocumenteerd, in repository, getest	‘Ergens in custom/’, auteur weg
Staging	Dicht bij productie, herhaalbaar	Alleen productie of lege demo
Eigenaarschap	Pakketeigenaar benoemd	‘Draait al jaren, niemand aankomen’

Tabel ter oriëntatie, geen scorekaart. Eén diep ingrijpende, niet-onderhouden uitbreiding kan riskanter zijn dan vijf oppervlakkige.

3. Typische wrijvingspunten in detail

3.1 Ontbrekende doelversie

SuiteCRM 8 is qua architectuur niet ‘SuiteCRM 7 in een nieuw jasje’. Pakketten die alleen voor 7.x zijn onderhouden, zijn niet betrouwbaar ‘op een of andere manier mee te nemen’. Of er is een ondersteunde versie voor uw 8.x-doellijn, of u plant vervanging, uitschakeling of eigen werk.

3.2 Dubbele functies

Twee factuuroplossingen, twee e-mailhulpen, twee workflowuitbreidingen: inhoudelijk ontstaat dubbel beheer, technisch dubbele hookketens en een onduidelijke gezaghebbende bron. Vóór de upgrade loont de vraag: welke oplossing is leidend en welke bestaat alleen historisch?

3.3 Maatwerkcode zonder afspraken

Projectspecifieke aanpassingen zijn legitiem. Zonder versiebeheer, korte beschrijving (‘welke hook, welke module, welke bedrijfsbehoefte’) en testgeval worden ze de blinde passagier van elke upgrade.

3.4 Gegevens- en bestandsvolume

Ook met nette pakketten verlengen grote hoeveelheden bijlagen en historie de kopieer-, back-up- en testvensters. Dit is geen plug-inprobleem in strikte zin, maar vermenigvuldigt elke mislukte poging.

4. Werkmodel: van lijst naar beslissing

Een bruikbare aanpak in vier rondes:

1. Inventaris (1–2 dagen focus, afhankelijk van grootte): Geïnstalleerde pakketten, versies, laatst bekende beheerder, ‘in productie ja/nee’, betrokken modules.
2. Risicoklassen: A = blokkeert kernproces, B = belangrijk maar te omzeilen, C = historisch/optioneel. Alleen A en B moeten vóór de upgrade een duidelijk plan hebben.
3. Staging met een doel: Niet ‘eenmaal upgraden en kijken’, maar: vastgelegde testgevallen (aanmelding, lead→verkoopkans, e-mail, een rapportage, een kritiek maatwerkproces).
4. Beslissing documenteren: behouden (met versie), vervangen, uitschakelen of bewust ‘na de upgrade opnieuw bouwen’. ‘Later’ zonder datum is geen beslissing.

5. Enkele afgestemde modules versus veel losse add-ons

Afgestemde modulesuites veranderen de risicostructuur: minder onafhankelijke releasecycli, gezamenlijke aannames over SuiteCRM-versies, vaak gezamenlijke gebruikers- en beheerpatronen. Dit is geen automatisch kwaliteitsbewijs – slechte suites bestaan – maar het testgebied wordt beter planbaar als een aanbieder intern rekening houdt met de combinatiematrix.

Losse add-ons blijven zinvol als ze beperkt, goed onderhouden en duidelijk afgebakend zijn. Het probleem is ongecontroleerde opstapeling zonder eigenaar.

6. Wat deze tekst bewust niet beweert

• Geen algemene uitspraak ‘communityplug-ins zijn slecht’.
• Geen garantie dat gebundelde suites elke upgrade risicovrij maken.
• Geen algemene besparingen in uren of kosten – die hangen af van inventaris en discipline.

Als u hierna maar één ding doet: maak een lijst van de actief gebruikte uitbreidingen en geef aan wie er inhoudelijk en technisch verantwoordelijk voor is. Zonder die lijst blijft elke upgrade een gok.

← Terug naar het magazine