Cómo evité errores con formularios en Contact Form 7 (y reducir horas de trabajo a mi cliente)
Hace unas semanas me llegó una consulta de un cliente que llevaba tiempo gestionando su portfolio en WordPress. Tenía una sección personalizada de Portfolio con decenas de entradas, y al final de cada una de ellas añadía manualmente el shortcode de un formulario de contacto con Contact Form 7.
El problema, como suele pasar con los procesos manuales repetitivos, es que los errores se acumulan sin que uno se dé cuenta.
El caos silencioso de los shortcodes manuales
El cliente gestionaba su web en dos idiomas: catalán y castellano. Tenía dos formularios de contacto distintos, uno para cada idioma, y los añadía a mano dentro del contenido de cada entrada del portfolio.
El resultado, con el tiempo, fue el siguiente:
• En algunas entradas en castellano aparecía el formulario en catalán, y viceversa.
• Varios formularios habían sido eliminados en algún momento, pero sus shortcodes seguían presentes en el contenido. WordPress, en ese caso, muestra un mensaje de error: «Este formulario no existe» o «Formulario no encontrado».
• El cliente tenía que recordar, entrada por entrada, cuál de los dos shortcodes debía pegar, lo cual era una fuente constante de confusión.
Todo esto no es culpa del cliente. Es el resultado natural de delegar en procesos manuales algo que debería estar automatizado.
La solución: detectar el idioma y mostrar el formulario correcto desde el template
En lugar de depender de que el cliente introduzca el shortcode correcto cada vez, la solución es incluir la lógica directamente en el template de PHP de la entrada de portfolio. Así, el formulario aparece siempre de forma automática, sin que el cliente tenga que hacer nada.
El código detecta el idioma activo de la página y muestra el formulario correspondiente.
Es compatible con los plugins de traducción más habituales: WPML, Polylang y el sistema de idiomas nativo de WordPress.
<?php
// Detectar idioma actual (compatible con WPML, Polylang y WordPress nativo)
function get_cf7_shortcode_by_lang() {
$lang = '';
// WPML
if ( defined('ICL_LANGUAGE_CODE') ) {
$lang = ICL_LANGUAGE_CODE;
}
// Polylang
elseif ( function_exists('pll_current_language') ) {
$lang = pll_current_language();
}
// WordPress nativo (locale: ca, ca_ES, es_ES, es, etc.)
else {
$locale = get_locale();
$lang = substr($locale, 0, 2);
}
if ( $lang === 'ca' ) {
return '[contact-form-7 id="dcd83fa" title="contacte"]';
} elseif ( $lang === 'es' ) {
return '[contact-form-7 id="d9829b1" title="contacto"]';
}
// Fallback: castellano por defecto
return '[contact-form-7 id="d9829b1" title="contacto"]';
}
?>
Cómo funciona la detección de idioma
El siguiente código se añade directamente en el archivo template de PHP de la entrada de portfolio. Su función es detectar automáticamente el idioma en el que el visitante está viendo la página y mostrar el formulario de contacto correcto en cada caso, sin que el cliente tenga que hacer nada manualmente.
Primero se declara una variable $lang vacía que almacenará el código de idioma detectado.
A continuación se comprueban tres opciones en orden de prioridad para detectar el idioma activo:
- Si la web usa WPML, se lee la constante
ICL_LANGUAGE_CODEque este plugin define automáticamente. - Si la web usa Polylang, se llama a la función
pll_current_language()que devuelve el idioma actual. - Si no hay ningún plugin de traducción, se usa la función nativa de WordPress
get_locale(), que devuelve valores comoca_ESoes_ES. Consubstr(..., 0, 2)se extraen solo los dos primeros caracteres (caoes), que es lo que nos interesa.
Finalmente, una vez conocido el idioma, se evalúa:
- Si el idioma es
ca(catalán), se renderiza el formulario de contacto en catalán mediantedo_shortcode(). - En cualquier otro caso, se muestra el formulario en castellano, que actúa como idioma por defecto.
De esta forma, aunque el cliente añada nuevas entradas al portfolio en el futuro, el formulario correcto aparecerá siempre de forma automática, sin riesgo de confusiones ni de shortcodes rotos.
Puntos importantes antes de aplicarlo
Elimina los shortcodes del contenido. Si el cliente ya tenía shortcodes añadidos manualmente dentro de las entradas, hay que eliminarlos. De lo contrario, el formulario aparecerá dos veces en la página.
El truco del almendruco:
Eliminar los formularios manualmente sería una locura. Utiliza un plugin como «Better Search Replace» para sustituir el shortcode ya creado por un campo vacío.
Haz clic en la imagen para acceder al repositorio de WordPress y descargar el Plugin.
Conclusión
Este tipo de automatizaciones pequeñas son las que marcan la diferencia en el mantenimiento diario de una web. Delegar en el cliente la responsabilidad de insertar el shortcode correcto en cada entrada es una fuente garantizada de errores. Mover esa lógica al template, donde pertenece, hace que la web funcione bien siempre, independientemente de lo que haga o deje de hacer el cliente en el editor.
Si gestionas portfolios o cualquier tipo de custom post type con formularios de contacto en webs multilingües, te recomiendo revisar si hay shortcodes insertados manualmente que puedan automatizarse de esta forma. El tiempo de implementación es mínimo y el ahorro en correcciones futuras, considerable.
¿Tienes este problema en tu web o uno parecido? Ofrezco consultoría WordPress. Contáctame y lo vemos juntos.
