Cerca

Paraules clau suggerides:
WordPress no és una
WordPress no és una

Imaginem tres projectes web que utilitzen WordPress.El primer és un web corporatiu construït amb…

La vulnerabilitat no
La vulnerabilitat no

Un web pot funcionar perfectament i, tot i així, estar exposat a una vulnerabilitat crítica.Les…

Per què recordem unes
Per què recordem unes

Hi ha imatges que reconeixem gairebé de seguida, fins i tot quan amb prou feines en sabem res. Les…

WordPress no és una tecnologia: és un ecosistema

WordPress no és una tecnologia: és un ecosistema

Imaginem tres projectes web que utilitzen WordPress.

El primer és un web corporatiu construït amb una plantilla comercial, un editor visual i diversos plugins. El seu equip pot actualitzar continguts sense coneixements de programació. El segon utilitza un tema propi i funcionalitats desenvolupades a mida per respondre a necessitats específiques. En el tercer, WordPress funciona únicament com a gestor de continguts: el web visible es desenvolupa per separat, potser amb React, i obté la informació mitjançant una API.

Tots tres projectes comparteixen el mateix CMS. Tanmateix, la seva arquitectura, la seva experiència d'administració i les seves necessitats de manteniment poden ser molt diferents.

Per això, afirmacions com «WordPress és lent», «WordPress és flexible» o «WordPress és difícil de mantenir» resulten incompletes. Poden descriure determinats projectes, però no necessàriament la plataforma en totes les seves formes.

WordPress no funciona de manera aïllada. Allò que veiem com un únic web és el resultat de decisions sobre components, desenvolupament, infraestructura i serveis. WordPress és el punt de partida, no una descripció completa del que hem construït.

Per comprendre'n els avantatges i les limitacions, hem de mirar més enllà del seu nucli.

El nucli és només una part del que utilitzem

El nucli de WordPress, o core, proporciona les funcions fonamentals per administrar usuaris, continguts i publicacions. Però poques vegades constitueix per si sol tot el que necessita un projecte.

Al seu voltant incorporem temes que defineixen la presentació, plugins que n'amplien les funcionalitats, proveïdors d'allotjament que gestionen la infraestructura, integracions amb serveis externs i, de vegades, desenvolupaments personalitzats. En una mateixa instal·lació poden conviure codi mantingut per la comunitat de WordPress amb productes comercials i solucions desenvolupades per una agència.

Aquesta combinació planteja una qüestió que no sempre és visible des del tauler d'administració: no tots els components avancen al mateix ritme ni estan sota la responsabilitat de les mateixes persones.

L'equip que manté el nucli estableix les seves prioritats. Cada fabricant de plugins o temes decideix com i quan actualitza els seus productes. Un proveïdor d'allotjament controla una part de l'entorn tècnic, mentre que una agència pot encarregar-se de les personalitzacions. Cada part té el seu propi calendari, les seves condicions i els seus límits de responsabilitat.

Això no converteix WordPress en una excepció. El programari modern acostuma a construir-se amb peces de múltiples procedències. El que és singular del seu ecosistema és la facilitat amb què aquestes peces es poden incorporar i combinar, fins i tot quan qui administra el lloc amb prou feines percep les relacions que es creen entre elles.

Utilitzar una única plataforma de gestió no significa dependre d'un únic proveïdor. I aquesta diversitat, tot i que exigeix certes precaucions, també és una de les seves grans fortaleses.

El gran avantatge de no haver de construir-ho tot

No totes les organitzacions necessiten desenvolupar el seu propi gestor de continguts, programar un formulari o crear des de zero una integració amb una plataforma de comerç electrònic. Una de les raons de la permanència de WordPress és que permet aprofitar solucions que altres ja han construït.

Una petita empresa pot posar en marxa un web professional sense finançar un desenvolupament completament personalitzat. Una organització sense ànim de lucre pot gestionar donacions o inscripcions. I un projecte més complex pot connectar el seu web amb eines de màrqueting o sistemes empresarials sense haver de desenvolupar tota la integració des del principi.

L'avantatge tampoc no és únicament econòmic. Hi ha una àmplia disponibilitat de professionals, documentació i coneixements especialitzats. És possible trobar equips amb experiència en rendiment, accessibilitat, comerç electrònic o gestió editorial, i donar continuïtat a projectes desenvolupats inicialment per altres persones.

Reutilitzar solucions permet dedicar més recursos a allò que realment diferencia cada projecte. No haver d'inventar-ho tot és un avantatge important.

Però disposar d'una eina per a gairebé qualsevol necessitat també pot canviar la nostra manera de decidir. Quan sorgeix un requisit, és temptador buscar un plugin i instal·lar-lo abans de preguntar-nos com hauria d'encaixar aquesta funcionalitat en el conjunt.

Que una solució existeixi i funcioni no implica que sigui la més adequada. Pot utilitzar estructures de dades difícils de traslladar, introduir processos poc compatibles amb altres eines o condicionar futures ampliacions. Desenvolupar alguna cosa a mida tampoc no garanteix un resultat millor: totes dues opcions necessiten criteri.

La fortalesa de l'ecosistema rau a oferir alternatives. La responsabilitat d'escollir-les continua sent nostra.

Quan cada solució introdueix una nova dependència

La complexitat d'un web no sempre es pot mesurar comptant plugins o calculant quant codi conté. El que sol ser decisiu són les relacions entre els seus components.

Un plugin necessita una versió determinada de PHP. Un tema inclou una biblioteca de JavaScript que també utilitza una altra extensió. Una personalització consulta dades emmagatzemades per un proveïdor extern. Una integració depèn que una API mantingui el seu funcionament.

Durant mesos tot pot funcionar correctament. Després arriba una actualització, canvia una API o es deixa de mantenir una biblioteca. Cap component no ha d'estar necessàriament mal desenvolupat perquè el conjunt comenci a donar problemes: n'hi ha prou que els seus canvis no siguin compatibles entre si.

Podem anomenar-ho complexitat acumulada: a mesura que augmenten les relacions entre components, resulta més difícil anticipar com afectarà una modificació la resta del sistema.

Per això, deu plugins relativament independents poden ser més senzills de mantenir que tres d'estretament relacionats. I un web amb poques extensions pot ser fràgil si una d'elles sustenta processos essencials que cap altra eina no pot substituir fàcilment.

Tenir moltes funcionalitats no equival a mantenir-ne el control. Aquest control no exigeix programar-ho tot des de zero ni rebutjar dependències externes. Significa saber quins elements són crítics, com es relacionen, qui els manté i quines alternatives tenim si cal modificar-los o substituir-los.

Una arquitectura amb responsabilitats delimitades, documentació suficient i proves abans d'actualitzar no elimina tots els riscos, però en facilita la gestió. L'objectiu no és evitar l'evolució del sistema, sinó que cada canvi sigui tan predictible com sigui possible.

A WordPress, on ampliar funcionalitats pot ser tan fàcil com instal·lar una extensió, aquesta distinció és especialment important: la rapidesa d'implementació i la sostenibilitat d'una decisió tècnica no són el mateix.

Un ecosistema també és una economia

Darrere de WordPress hi ha una indústria d'empreses d'allotjament, fabricants de plugins i temes, desenvolupadors independents, agències i proveïdors de suport. Una part d'aquesta activitat contribueix directament al projecte de codi obert; una altra part construeix productes i serveis al seu voltant.

No hi ha cap contradicció automàtica entre el programari lliure i l'activitat comercial. Desenvolupar, actualitzar i oferir suport a una eina requereix recursos. Els models de negoci permeten sostenir moltes solucions que, d'una altra manera, difícilment existirien.

Tanmateix, els interessos de proveïdors i clients no sempre coincideixen. Una empresa pot modificar el preu d'una subscripció, reorganitzar els seus plans o deixar de mantenir un producte per raons comercials legítimes. Per a qui l'utilitza com a peça central del seu web, aquestes decisions poden tenir conseqüències importants.

Imaginem una organització que gestiona les seves vendes mitjançant una extensió concreta. Encara que tingui accés a les seves dades i a una part del codi, canviar d'eina potser implica migrar informació, refer processos i tornar a formar el seu equip. El cost de sortida pot ser molt més gran que el preu de la llicència.

Aquí apareix una distinció fonamental: tenir accés al codi no sempre significa tenir capacitat pràctica per substituir una solució. Una llicència lliure ofereix drets importants, però mantenir pel propi compte una eina abandonada també pot exigir coneixements i recursos que l'organització no té.

Abans d'adoptar un component convé considerar qui el desenvolupa, com es finança, quin suport ofereix i què passaria si desaparegués. Això no significa desconfiar del programari comercial ni suposar que una eina gratuïta serà menys fiable. Significa incorporar la continuïtat del proveïdor i el cost de canvi a l'anàlisi tècnica.

Les agències també han d'examinar les seves pròpies decisions. L'eina que permet lliurar un web més de pressa no sempre serà la més convenient per a qui l'haurà de mantenir durant anys.

Escollir tecnologia implica, en part, escollir relacions econòmiques. El que és important és comprendre-les abans que es converteixin en dependències difícils de gestionar.

La comunitat no és un departament de suport

WordPress també compta amb alguna cosa que no es pot reduir als seus productes comercials: una comunitat internacional que contribueix al nucli, corregeix errors, tradueix, documenta, organitza trobades i comparteix coneixement.

Aquesta xarxa facilita trobar respostes, aprendre d'experiències alienes i mantenir viva una plataforma que no depèn d'un únic equip de desenvolupament. És un dels grans actius del projecte.

Però una comunitat que contribueix al desenvolupament d'una tecnologia no és el mateix que un equip contractat per mantenir el nostre web.

Que un plugin tingui un repositori públic o un fòrum de suport no significa que el seu autor estigui obligat a respondre totes les consultes. Que el nucli rebi actualitzacions no garanteix la compatibilitat de qualsevol combinació de temes, extensions i codi personalitzat. I que un proveïdor ofereixi suport sobre el seu producte no implica que hagi de resoldre qualsevol conflicte originat per tercers.

Pensem en una incidència després d'una actualització. L'allotjament funciona correctament; el proveïdor del plugin assenyala una incompatibilitat amb el tema; i qui manté el tema atribueix l'error a una personalització. Pot ser que cadascú tingui raó dins del seu àmbit. Tanmateix, el web continua sense funcionar.

L'exemple revela una diferència essencial: que cada peça tingui un responsable no garanteix que algú respongui pel conjunt.

Aquí entra la responsabilitat professional de qui dissenya, integra i manté el projecte. No significa que una agència hagi d'oferir suport indefinidament ni que el manteniment estigui inclòs automàticament en el desenvolupament inicial. Significa que convé establir qui supervisa les actualitzacions, qui investiga les incidències i sota quins acords es duen a terme aquestes tasques.

WordPress es pot utilitzar sense pagar una llicència pel seu nucli, però això no converteix el seu manteniment en gratuït. Cal dedicar temps a supervisar canvis, fer proves i resoldre problemes. La comunitat pot proporcionar eines i coneixement; no pot assumir responsabilitats que mai no se li han assignat.

Reconèixer aquest límit també és una manera de respectar la feina de qui contribueix al programari lliure. La seva aportació té un valor enorme precisament perquè no hem de confondre-la amb una obligació de suport permanent.

Conclusió

Tornem als tres projectes del començament. Comparteixen WordPress, però les seves decisions d'arquitectura, les seves dependències i les seves necessitats de manteniment són diferents. Per això, preguntar si «WordPress és una bona solució» sense conèixer el projecte aporta menys del que sembla.

Escollir WordPress no consisteix únicament a seleccionar un CMS. També suposa decidir quins components utilitzar, en quins proveïdors confiar, com organitzar el desenvolupament i qui es farà càrrec de la seva evolució.

La solució no és instal·lar menys plugins per principi ni evitar els serveis externs. És entendre què hem incorporat i conservar prou capacitat per intervenir quan canviïn les circumstàncies.

La qualitat d'un projecte WordPress depèn tant de la plataforma com del criteri amb què se n'han escollit, integrat i mantingut els components. Potser la pregunta més útil no és què podem construir amb WordPress, sinó fins a quin punt comprenem realment el que hem construït.

Però hi ha alguna cosa més. Mentre aquest ecosistema creixia, la web també canviava profundament: els dispositius, les expectatives de rendiment, la seguretat, les arquitectures i la manera de crear i consumir continguts.

Fes-te membre

Rep les últimes novetats directament al teu correu. Sense correu brossa.

Això ens porta al següent article de la sèrie, La web que WordPress va ajudar a construir ja no existeix, i a una nova pregunta: fins a quin punt WordPress continua responent a les necessitats d'una web que ja no s'assembla a aquella per a la qual va ser creat?

Comentaris
Comentari