Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Php Mysql Rendiment Manteniment

Les accions programades WooCommerce s’acumulen i deixen de processar-se

Repara el backlog d'Action Scheduler revisant WP-Cron, hooks fallits, workers PHP, locks MySQL i reintents segurs.

WooCommerce i moltes extensions utilitzen Action Scheduler per a webhooks, subscripcions, correu, neteja i sincronització. Una cua Pending creixent significa que es crea treball més ràpid del que es completa; molts Failed iguals indiquen un callback incapaç d’acabar.

No eliminis la cua per reduir el número. Pot contenir pagaments, reemborsaments o fulfilment pendents de conciliació.

Mesura el backlog

A WooCommerce > Estat > Accions programades registra Pending, Failed, In-progress i l’hora més antiga.

- edat de la pendent més vella
- accions noves per minut
- completades per minut
- hooks amb més errors
- durada mitjana i màxima

Consulta arguments només amb autorització; poden contenir ID de client o comanda.

Confirma que s’invoca el runner

WordPress activa cron amb trànsit. Revisa DISABLE_WP_CRON i si existeix un cron real.

Utilitza cPanel o Plesk per cridar el lloc amb PHP/HTTP suportat i una freqüència raonable. Confirma lloc i versió PHP. No executis diversos crons solapats sense mesurar concurrència.

En multisite, el scheduler ha d’arribar a la botiga on viuen les accions. Cridar només el lloc principal pot deixar una altra cua immòbil.

Comprova als logs que cada invocació iniciï un runner i quantes accions reclama. Una resposta 200 de wp-cron.php no prova progrés. Compara l’ID més antic i el recompte completat abans i després.

Llegeix el primer error repetit

Agrupa per hook i error, no obris només l’últim. Relaciona un cas amb logs PHP i del proveïdor.

Una funció absent apunta a incompatibilitat; 401 a credencials; timeout a resultat extern desconegut; deadlock a escriptures concurrents. Corregeix la causa comuna abans de reintentar un lot.

Comprova workers i límits

El runner necessita processos PHP i memòria. Si estan ocupats per peticions lentes, cron arriba però no avança.

Revisa gràfics, fatals i saturació. Augmenta capacitat només després de saber si una acció monopolitza cada worker. Divideix importacions en unitats acotades.

Calcula throughput: accions noves per minut contra completades. Si la cua creix sense errors, redueix cost, ajusta lots o afegeix capacitat amb límits. Si un hook consumeix tot el temps, separa’l perquè no bloquegi pagaments i correus.

Revisa locks i taules

Action Scheduler reclama i registra treball a MySQL. Consultes lentes, disc ple o claims abandonats redueixen rendiment.

Utilitza mètriques i eines oficials compatibles. Fes backup abans del manteniment. No truncar taules: la història serveix per deduplicar, auditar i diagnosticar.

Revisa espai, índexs esperats i consultes de claims. Un disc gairebé ple pot impedir escriure logs o alliberar accions. Més runners només augmentarien la pressió.

Fes callbacks idempotents

La mateixa acció es pot repetir després de timeout. Pagament, estoc i fulfilment han de reconèixer una operació completada.

$order = wc_get_order( $order_id );
if ( ! $order ) {
    throw new RuntimeException( 'Comanda no disponible per a la tasca' );
}

Desa una referència externa estable i consulta resultats incerts abans de repetir. No registris secrets o payloads personals.

Recupera per lots controlats

Concilia accions sensibles amb proveïdor i comanda. Corregeix l’arrel, executa una de risc baix i verifica efectes.

Defineix mida, pausa i criteri de parada. Després de cada lot compara estats externs, no només Completed. Atura’t davant duplicats i conserva una llista de referències.

Evita un altre bloqueig silenciós

Alerta per edat de Pending, taxa d’error i creixement, no pel total històric. Prova cron després de migracions, canvis PHP o regles de seguretat.

Completa una comanda controlada i confirma que correu, webhook, estoc i tasques externes acabin una vegada. La latència de cua és una mètrica de salut transaccional.

Revisa-la en períodes de poc i molt trànsit.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència