Desarrollo de WordPress
personalizado

Estándares de código de WordPress (PHPCS WPCS) aplicados en CI, autocarga PSR-4 mediante Composer, clases con namespace, registro adecuado de hooks con callbacks con nombre (sin closures asociados a acciones que no puedes desenlazar), verificación de capacidades en cada acción de administración, verificación de nonce en cada envío de formulario, SQL preparado con $wpdb->prepare(), sanitización en la entrada + escape en la salida y pruebas unitarias en PHPUnit. Los plugins distribuibles se entregan con archivos .pot y comentarios para traductores.

Registra tipos y campos personalizados con register_graphql_object_type y register_graphql_field; expone conexiones con register_graphql_connection; las funciones resolver viven en clases PHP con alcance de responsabilidad única. Los campos de ACF aparecen automáticamente mediante la extensión WPGraphQL for ACF. Consultas persistentes cuando el cliente es consistente (Next.js). Autenticación con JWT (wp-graphql-jwt-authentication) o contraseñas de aplicación.

High-Performance Order Storage reemplaza el esquema de pedidos de wp_posts / wp_postmeta con tablas dedicadas. Es obligatorio en nuevas instalaciones de WooCommerce y es el valor predeterminado en las actualizaciones a la versión 8.2 o posterior. Auditamos cada fragmento de código, plugin e integración personalizados que toque pedidos para verificar la compatibilidad con HPOS (llamadas a la API WC_Order vs. WP_Post), ejecutamos la migración por etapas (modo de sincronización → modo de cambio), verificamos las operaciones de pedidos en las nuevas tablas y solo entonces dejamos obsoletas las lecturas heredadas.

Object Cache Pro sobre Redis (lecturas de caché en submilisegundos vs. el valor predeterminado de WP), caché de página mediante el host (WP Engine, Kinsta) o Cloudflare APO, caché de fragmentos para widgets de administración costosos, caché de transients para llamadas a APIs externas, optimización de consultas con índices adecuados en tablas personalizadas, $wpdb->prepare() en todas partes y una pasada de perfilado con New Relic + Query Monitor antes del lanzamiento. Metas: LCP <2.5s en las páginas de destino clave, INP <200ms, sin consultas N+1 en la ruta crítica.

Sí. Bloques nativos React / JSX con @wordpress/create-block, registrados con block.json, callbacks de renderizado en el servidor donde el SEO importa, InspectorControls + BlockControls del lado del cliente para la experiencia del editor y un schema de block.json correcto. Bloques ACF donde la experiencia del editor se beneficia de la interfaz de campos de ACF. Patrones de bloques y patrones reutilizables donde el contenido es texto repetitivo.

Instalaciones al estilo Bedrock gestionadas con Composer (wp-core + plugins + temas como dependencias), CI en GitHub Actions que ejecuta PHPCS WPCS + PHPUnit + Playwright en cada PR, despliegues con WP-CLI por SSH (sin FTP), entornos de staging que replican producción (multi-entorno de WP Engine, staging de Kinsta o un host de staging dedicado) y scripts de migración de base de datos con control de versiones cuando cambian los modelos de contenido.

Sí, y a menudo es el proyecto en sí. Auditamos el conjunto de plugins, los temas personalizados, los mu-plugins, las tablas personalizadas y cualquier código personalizado heredado. Los hallazgos se entregan en un informe escrito: mantener, refactorizar, reemplazar, dejar obsoleto. Luego programamos la limpieza por fases según las prioridades del negocio, normalmente rendimiento y seguridad primero, y las nuevas funciones sobre una base limpia.

Primero descubrimiento y alcance (normalmente un sprint pagado de 2 semanas para trabajo no trivial: no cotizamos $50k de desarrollo de plugins personalizados en una llamada de 30 minutos). Luego fases de precio fijo para trabajo bien delimitado y T&M para retainers de desarrollo continuo. Verás un rango en la primera llamada después de una conversación de alcance.