Un pressupost útil de reparació WordPress comença amb una incidència concreta i acaba amb una manera acordada de comprovar la feina. Entre tots dos punts hi ha els accessos, el diagnòstic, la correcció, la recuperació i aquella pregunta que sempre acaba arribant: què inclou exactament aquest preu?
Si has d’encarregar una reparació el 2027, utilitza aquest brífing per comparar la mateixa feina entre proveïdors. És una estructura original de contractació i acceptació. L’exemple és fictici: no descriu un client, una oferta tancada ni la promesa de resoldre qualsevol avaria en una sessió.
Ja hi ha una guia per recopilar evidències de hosting abans de demanar una reparació. Fes-la servir per preparar el paquet tècnic. Aquí concretem l’encàrrec comercial: què demanes, qui pot autoritzar-ho i què permetrà donar-ho per acabat.
Comença per la tasca del negoci que ha deixat de funcionar
«La web està trencada» pot significar caiguda pública, administració en blanc, notificació perduda o error en un navegador. Aporta la URL pública i la tasca que intentava completar la persona afectada.
Explica a qui afecta i què continua funcionant. Una portada a la memòria cau diu poc sobre si l’editor pot desar o una consulta nova arriba a vendes. Separa observació i teoria: «va començar després d’actualitzar» és una dada útil, però encara no demostra la causa.
Descriu la conseqüència amb informació que puguis sostenir: consultes sense verificar, equip sense poder publicar o clients bloquejats en un pas concret. Si es desconeix quantes operacions estan afectades, deixa-ho indicat en lloc de convertir una estimació en facturació perduda.
Delimita la cronologia de la incidència
Registra quan es va detectar, l’últim ús correcte conegut i els canvis recents de publicació, hosting, DNS o configuració. Inclou zona horària. Per comparar registres, el tècnic necessita un interval utilitzable, no «ahir en algun moment».
Anota també intents de solució, qui els va fer i què va passar. Desactivar un plugin, començar una restauració des de hosting o purgar memòria cau des d’una agència canvia l’evidència disponible. Conserva un registre compartit mentre la incidència continuï oberta.
Si hi participen diversos equips, acorda qui coordina. Hosting, desenvolupador i integració poden controlar trams diferents. Convé evitar que tothom canviï el mateix sistema sense veure les intervencions dels altres.
Separa diagnòstic, reparació i recuperació de registres anteriors
Pregunta si el pressupost inclou identificar la causa, aplicar una correcció acotada o totes dues coses. Quan el diagnòstic sigui una fase amb preu propi, concreta què lliura i quina autorització necessita la feina posterior.
Restaurar el comportament futur i recuperar registres ja afectats poden ser encàrrecs diferents. El formulari pot tornar a lliurar mentre continuen pendents les consultes anteriors. La web pot tornar després d’una restauració i necessitar una altra decisió per al contingut creat després de la còpia.
Escriu aquests límits a la proposta. Un abast inicial petit pot ser útil si allò pendent té responsable i decisió següent. Una reparació ben delimitada es gestiona millor que una promesa general d’arreglar-ho tot.
Compara l’abast abans de comparar els totals
| Partida | Què ha d’identificar la proposta | Límit d’autorització |
|---|---|---|
| Diagnòstic | Recorregut afectat, evidència necessària i resultat que es lliura | Què passa si la causa continua sense resoldre’s |
| Preparació de recuperació | Còpia disponible, mètode de restauració i dades recents afectades | Qui aprova restaurar o restringir temporalment |
| Correcció | Component o configuració inclosos i dependències | Quines troballes requereixen un altre pressupost |
| Verificació | Tasca original, condició del visitant i resultat esperat | Qui accepta l’evidència |
| Traspàs | Registre de canvis, pendents i tancament d’accessos | Qui s’ocupa de cada continuació |
Completa les mateixes files per a cada proveïdor. Un total menor pot cobrir només diagnòstic; un altre pot incloure intervenció i repetició de proves. Només es poden comparar quan queda visible què compra cada import.
Identifica sistemes i responsables dels accessos
Indica CMS, hosting o plataforma gestionada, integracions rellevants i qui les controla. La consulta pública necessita aquest inventari, no contrasenyes, claus privades ni exportacions de clients.
Després d’acordar l’abast, prepara l’accés necessari mitjançant el procés segur triat. Defineix finalitat, responsable i retirada o revisió prevista. Un usuari WordPress pot quedar curt per a un problema de hosting; un accés ampli al servidor pot sobrar per a un canvi de contingut.
Fes visibles les dependències externes. Si ningú no pot accedir al correu o a DNS, la proposta ha de reflectir el límit i com obtenir l’evidència pendent. No es pot verificar un sistema que el responsable de la intervenció no pot inspeccionar.
Acorda els límits de recuperació abans d’intervenir
Pregunta quina còpia hi ha, què conté i com es restauraria. Copiar arxius i fer còpia de la base de dades protegeix elements diferents. Comprova data i registres que podrien desaparèixer si es tornés a un estat anterior.
Decideix qui pot autoritzar aquesta conseqüència. Comandes, consultes, reserves i canvis editorials posteriors a la còpia necessiten atenció abans d’una tornada enrere general. Qui autoritza ha de conèixer aquest límit.
El tècnic ha de conservar l’evidència rellevant i acotar la intervenció a allò que sosté el diagnòstic. Si cal depurar, la documentació de depuració de WordPress —en anglès— és la referència tècnica. Entorn de proves, registres i exposició a producció han d’encaixar amb la feina acordada.
Fes visibles l’estat i el responsable
Una reparació necessita responsable i estats comprensibles: pendent d’evidència, diagnòstic en curs, esperant autorització, correcció aplicada, verificació pendent o tancat. Tria els que representin el vostre procés i explica qui mou la feina entre ells.
La referència ajuda a parlar d’estat i assignació. L’acord necessita també persona responsable, canal de comunicació i procés d’autorització reals. Marcar un tiquet resolt és una acció administrativa; la verificació acordada sosté el tancament de la feina.
Fixa un ritme de comunicació que faciliti decisions
Acorda quan rebràs novetats i què han d’incloure: observació actual, acció, resultat, bloqueig i decisió següent. La freqüència depèn d’urgència i feina. Demana un acord concret en lloc de deduir temps d’una descripció general del servei.
Assigna qui aprova ampliar diagnòstic, canviar un sistema extern o aplicar una restricció temporal. Desa aquestes decisions en un lloc comú perquè qui recupera el servei vegi l’última situació autoritzada.
Una actualització útil pot explicar que la causa continua oberta i identificar la comprovació següent. L’absència d’una altra queixa encara no demostra que hagi funcionat una correcció.
Defineix l’acceptació al voltant de la tasca original
Escriu la prova abans d’intervenir. Per a una pantalla blanca pública, inclou contingut previst sota la condició del visitant afectat. Per a un error de l’administració, inclou la tasca real d’edició o gestió.
La guia de pantalla blanca i la d’administració en blanc amb web pública funcionant ajuden a separar aquests límits. Si falla el domini mentre respon el servidor, utilitza el diagnòstic d’IP davant de domini.
Registra resultat observat, data, entorn, URL i exclusions pendents. Afegeix comprovacions rellevants d’allò que podria haver quedat afectat sense convertir silenciosament l’encàrrec en una auditoria de tota la web.
Exemple de brífing: la pàgina carrega, però no es verifica una consulta
És un exemple fictici de contractació. Dona-li una referència com REPAIR-BRIEF-001 i conserva com a pendent tota prova encara no feta. Serveix per convertir incertesa en feina acotada.
Símptoma observat: carrega la pàgina de contacte, però el responsable no pot confirmar recepció d’una consulta de prova autoritzada. El brífing recull URL, hora i resultat visible. No pressuposa un error del proveïdor de correu.
Abast de diagnòstic: seguir una referència controlada per l’emmagatzematge admès, proveïdor de notificació i destinació prevista. El tècnic identifica accessos. CRM queda fora de la primera fase fins que estigui disponible el responsable.
Decisió de reparació: presentar error identificat i correcció proposada abans d’ampliar allò autoritzat. Definir per separat la revisió de consultes anteriors quan hi hagi una font recuperable.
Acceptació: repetir una prova nova permesa sota les mateixes condicions rellevants, confirmar etapes acordades i assenyalar la dependència pendent de CRM. Ni l’èxit visible ni un estat del proveïdor sense revisar permeten tancar tot el recorregut.
Compara supòsits i exclusions del pressupost
Pregunta com afectarien accessos absents, còpies no disponibles, components propis sense suport o un compromís de seguretat acabat de detectar. La resposta ha d’explicar decisió i autorització necessàries, sense fingir un import precís per a una causa desconeguda.
Comprova si s’inclouen costos externs, llicències, reconstrucció de contingut, investigació de seguretat i manteniment posterior. Cada proveïdor pot delimitar aquestes partides d’una altra manera. Fes-les visibles al costat del preu.
Revisa com defineix l’oferta l’acceptació i qualsevol període de seguiment. La paraula reparació no implica arreglaments futurs il·limitats. L’abast escrit ha d’explicar què passa si torna el símptoma original i com es valora una avaria diferent.
Preguntes que convé tancar abans d’acceptar
Com comparo hores i preu tancat?
Compara la mateixa feina autoritzada, evidència i exclusions. Per hores, acorda informació d’avanç, límit de despesa aprovat quan pertoqui i moment de consultar abans de continuar. Amb abast tancat, identifica supòsits i troballes que el canviarien. El format de preu no resol si s’hi inclouen dades anteriors, tercers o repetició de proves. Col·loca aquestes partides al costat de l’import i distingeix la fase de diagnòstic.
I si necessitem recuperar servei abans de conèixer tota la causa?
Acorda un objectiu provisional i els riscos. Una restauració temporal, resposta de manteniment o funció limitada pot ajudar a continuar mentre s’investiga. Registra què s’ha recuperat, què continua restringit i qui fa el pas següent. La resposta temporal no demostra que desaparegués l’error de fons. La proposta ha d’explicar com s’encarregaran diagnòstic i verificació finals.
Com s’accepta una reparació intermitent?
Descriu la condició original i acorda prova repetible, observacions que cal conservar i un període raonable de revisió. Anota mostra i reproducció del símptoma. Uns intents correctes no proven que mai tornarà, però aporten una base identificada per acceptar. Defineix quina evidència obriria una altra investigació i qui la rebrà. Això facilita decidir sense convertir una comprovació puntual en una garantia indefinida.
Puc demanar pressupost abans de compartir accessos?
URL pública, símptoma, hora i tasca comercial permeten una primera valoració. El proveïdor ha d’explicar què desconeix i si necessita una fase de diagnòstic controlada per pressupostar la correcció. Conserva visibles els supòsits de qualsevol estimació. L’accés es prepara després per a la finalitat acordada; la primera consulta pública es pot fer sense credencials.
Dues incidències observades: què hauria de contenir el tancament d’una reparació
El 25 d’octubre de 2026 vam documentar aquests dos problemes en webs de la nostra xarxa. Són intervencions pròpies, no casos de clients ni exemples ficticis. Serveixen per comparar lliuraments: símptoma, causa, canvi i comprovació. No hem mesurat quant va durar cada reparació ni calculat vendes recuperades.
WR-01. Una taula que s’enduia tota la pàgina cap a la dreta
Símptoma: a la guia de proves de formularis de Forms Not Sending, una finestra configurada a 412 píxels tenia un document de 517 píxels d’amplada. El bloc de l’article mesurava 622 píxels. La taula conservava els seus 620 píxels mínims i el desplaçament acabava afectant la pàgina. La taula havia decidit llogar-se un pis més gran.
Causa confirmada: el mínim automàtic de l’element dins la quadrícula impedia que el contingut s’estrenyés amb la finestra. El contenidor de la taula ja permetia desplaçament horitzontal, però el pare continuava eixamplant-se. La referència de MDN sobre min-width explica aquest mínim en elements de grid.
Canvi aplicat: vam permetre que els fills de la quadrícula s’encongissin amb min-width:0 i vam fixar la columna mòbil mitjançant minmax(0,1fr). La taula va mantenir el desplaçament dins del contenidor. La correcció va quedar en una extensió acotada als articles; el fitxer del tema va acabar amb el contingut original. No es va amagar el desbordament de tota la pàgina per dissimular el problema.
Comprovació pública: el registre posterior va donar 412 píxels de document per 412 de finestra. Ara hem repetit la visita pública en Chromium amb finestres de 412 i 1440 píxels: la pàgina hi cap i, en l’estreta, la taula es recorre dins del contenidor. Són mides de finestra d’un navegador d’escriptori, no proves en telèfons físics ni una matriu de tots els navegadors.
WR-02. L’interruptor de galetes deia una cosa i l’elecció desada, una altra
Símptoma: durant una revisió de l’article de rendiment i consentiment de Code GxP, la preferència d’analítica estava denegada i la visita mesurada no registrava les peticions de seguiment comptades. Tot i això, el panell servit des de memòria cau mostrava l’interruptor encès. Mirar només l’interruptor hauria donat un diagnòstic equivocat.
Causa confirmada: l’estat visual rebut a l’HTML no estava sincronitzat amb la categoria desada en aquell navegador. La reparació havia de reconciliar el control mostrat amb l’elecció existent; canviar la preferència del visitant perquè coincidís amb la pantalla hauria resolt el problema a l’inrevés.
Canvi aplicat: vam afegir un accés per reobrir les preferències existents i vam sincronitzar els interruptors en carregar i en obrir el panell. Aquest ajust llegeix l’elecció desada; no la substitueix. Vam renovar les respostes públiques en memòria cau afectades i vam retirar l’observador temporal utilitzat per mesurar.
Comprovació pública: la sèrie original va alternar tres visites amb rebuig i tres amb acceptació, totes en Chrome d’escriptori. Va registrar zero recursos dels orígens de seguiment comptats amb rebuig i dos en cada visita amb acceptació. En la repetició actual hem fet servir dos contextos nous de Chromium: triem rebutjar o acceptar amb la interfície, recarreguem i reobrim la configuració. L’interruptor coincideix amb la categoria desada en tots dos casos. Això verifica aquest recorregut; no constitueix una auditoria completa de privacitat ni demostra una millora de velocitat.
| Incidència | Abans | Criteri de tancament comprovat |
|---|---|---|
| WR-01 · Maquetació | Document de 517 px en una finestra configurada a 412 px. | Document de 412 px; taula amb desplaçament intern. |
| WR-02 · Preferències | Analítica denegada i control visual encès. | Després de triar, recarregar i reobrir, estat desat i control coincideixen. |
Per demanar pressupost, no cal conèixer per endavant la propietat CSS o l’origen de l’estat incorrecte. Sí que convé demanar aquest mateix fil: què fallava, què es va confirmar, què va canviar i en quines condicions es va repetir la prova. Una captura bonica del «després» pot acompanyar-lo; el tancament necessita alguna cosa que una altra persona pugui comprovar.
Tanca accessos i conserva un traspàs utilitzable
Demana una explicació breu de causa observada, canvi, verificació i pendents. Conserva identificadors i evidència tècnica necessaris per a continuïtat, mantenint credencials i dades personals innecessàries fora del document compartit.
Revisa accessos temporals i configuració de diagnòstic amb els responsables. Assigna seguiment, actualitzacions o implementació posterior. La reparació pot destapar una necessitat de manteniment; aquella feina continuada mereix el seu propi abast acordat.
Per demanar un pressupost de reparació d’una web WordPress, envia URL pública, símptoma original, cronologia aproximada, canvis recents i tasca que necessites recuperar. Website Repair revisa aquest context abans de demanar accessos o començar. Un brífing precís no ha de ser un document solemne. N’hi ha prou que la persona següent hi trobi alguna cosa útil per posar-se a treballar.