…que Wix es super atractivo (pero no todo lo que brilla es oro)

Tengo que trabajar con un colega en la construcción de un sitio web. Él usa Wix y yo tiro más para el lado de WordPress.

Pero como siempre me interesa aprender cosas nuevas, y ya tenía ganas de meterle mano al Wix, decidí que armaríamos en esa plataforma.

Lo primero es que es super atractiva, con colores, animaciones, una interfaz muy cuidad, con guías paso a paso, ayudas. Todo como para que el que tenga ganas le resulte fácil empezar a armar una página o sitio web. Casi parece un juego de Lego.

Pero algunas cosas se nota que están todavía las están incorporando, cosas que en WordPress ya las doy por echo (está bien, son casi 16 años y una comunidad gigante de desarrolo y soporte), pero las principales que necesitaba son:

  • Capacidad idioma
  • Que varios usuarios puedan editar (al mismo tiempo en diferentes partes)

Pero logramos resolver varias cosas y salimos adelante.

El principal problema fue el blog de entradas que el feed no cambiaba con el cambio de idioma. Hay una solución alternativa que propone la gente de Wix que es tagear las entradas por idioma y luego armar una página para cada feed de idioma y filtrar por el tag.

Otro problema que tuvimos, pero esto le puede pasar a cualquiera, es que en el home teníamos un ligthbox de video que reproducía automático al entrar, pero generaba problema con la animación de entrada de la cabecera y menú. Al cerrar el video desaparecía el menú y la cabecera.

La solución fue desactivas las animaciones de entrada (perdimos un poco de brillo en pos de la funcionalidad)

Sin embargo resulta interesante.

… que a veces resolver algunas cosas de WordPress son más simples de lo que parece.

Un cliente me contactó porque su sitio web en WordPress se había «desarmado un poco»: en el home algunas cosas se desejustaron de la maquetación (apenas) y lo más importante, en una sección ya no le aparecían las imágenes.

La sección en cuestión usa un armado con solapas para separar los contenidos ligados a días específicos de la semana. Cada día tenía cargada una serie de imágenes, a modo de flyers, para cada actividad. Había dejado «funcionar», o por lo menos eso parecía porque no aparecía cuando se visualizaba la página desde la parte pública.

Cuestión que me pongo a relevar qué plugins tenía instalados. Un montón, y algunos con funciones similares como los site builders.

Dado que no tenía forma de hacer un backup completo de la base de datos, quería tocar lo menos posible y no actualizar ningún plugin ni nada.

Mientras trataba de ofrecerle una maquetación alternativa con el builder que sí funcionaba (o al menos eso pensaba yo), que le permitiera cargar las imágenes y separarlas por día de la semana (y que no sea un choclazo, vamos, que quede amigable), me encuentro que al querer aplicarle la misma plantilla de página ¡el contenido dejó de aparecer!

El problema era que la página había estado usando una plantilla que no le correspondía: específicamente la de archives. Cuando hago el cambio en la página original que no funcionaba, ¡empezó a funcionar de nuevo!

Por cierto, también aprendí que los builders pueden ser atractivos al principio, pero tienen demasiados pasos para hacer cosas sencilla. Igualmente me resultó interesante la forma en que se manejaban:

… a preparar un WordPress para editar contenidos en HTML simplón ¡chau Dreamweaver!

La idea es tener un editor para formatear textos en HTML desde un editor visual, que los editores se puedan ingresar con clave y trabajar con una herramienta conocida, que se conserve el formato HTML, además que haga coloreado (highlight) de la sintaxis por si hay que tocar el código, y que puedan aplicar estilos CSS a los elementos desde un menú visual.

No interesa (por ahora) la opción de bloques que propone el Editor Gutenberg, pero no desecharlo, por lo que la instalación se hizo con WP 5.0.

Los plugins específicamente instalados:

Además están: WP Cerber Security de Gregory, el Resctric User Access de Joachim Jensen , Members de Justin Tadlock, WP2Static de Leon Stafford.

En el TinyMCE Advanced hay que habilitar en Configuración Avanzada la opción que mantenga los párrafos y saltos de línea, es decir, desactivar el autoformato que hace WordPress, y por otro lado, para agregar las class personalizadas como estilos de formatos hay que agregar en el archivo functions.php del theme activo el archivo editor-style.css que se debe crear a mano en el directorio, y luego tildar la opción en la configuración avanzada (mejorar esta explicación con un paso a paso)

Ideas a futuro:

Como el asunto es utilizar esta sola instalación para editar contenidos de muchos sitios una forma de separar es editar entradas y que cada sitio sea una categoría.

También se podría utilizar algún tipo de plugin que permita definir diferentes cabeceras y pie, o layout para las diferentes categorías y hojas de estilo personalizadas, ya que de esta manera se podría previsualizar «casi» cómo quedaría el contenido con el aspecto del sitio al que pertence.

…. que a veces las actualizaciones rompen todo lo que funcionaba bien

Tengo un cliente que usa WordPress y Woocomerce para atender una tienda online y hace unos días no podía actualizar la base de productos usando el importador de CSV porque aparecía un cartel de «Archivo no permitido por razones de seguridad».

Me puse a hacer pruebas por si era un problema del archivo CSV pero como todo estaba «normal» como siempre me puse a investigar en internet (yo no googleo) y encuentro que ya era un tema instalado en los foros de soporte:

https://wordpress.org/support/topic/csv-not-uploading/

Algunos proponen algún tipo de parche temporario agregando unos filtros al theme pero no funciona. Por ahora la única solución fue instalar un plugin que deshabilita el MIME TYPE CHECK

Por ahora funcionó y permitió subir el archivo.

Lo interesante es que en otro hilo del foto descubro ClassicPress como alternativa a WordPress. Habrá que probarlo.

https://gist.github.com/rmpel/e1e2452ca06ab621fe061e0fde7ae150#gistcomment-2788627

Y chau.

…a personalizar items del menú en WP según el idioma con qTranslate-X (o como es mejor leer el manual antes de tratear)

Tengo un sitio web en WordPress con el plugin qTranslate-X y 2 idiomas configurados: español e inglés. Y necesito apuntar un item del menú principal a 2 sitios distintos según el idioma.

Estaba a punto de ponerme a hacer una modificación al theme, aplicando algún tipo de filtro (con PHP o con javascript en el peor de los casos) y buscando la forma de obtener el idioma visualizado, se me ocurre leer en el sitio de desarrollo del plugin un poco la documentación por si hay algo… y encuentro las FAQ.

Una de ellas tenía la respuesta a lo que necesitaba hacer:

# How can I customize menu depending on the language?

If you wish a menu item not to show up for a specific language, remove its translation for that language from “Navigation Label” field in menu editor.

Entonces veo que la solución es duplicar el item del menú con 2 URL distinas, pero en cada idioma sólo dejo la Etiqueta de navegación que me interesa, de manera tal que el item con la etiqueta vacía en un idioma no se muestra.

La única desventaja es que si se llega a tener muchos items que deben cambiar la URL según el idioma, el menú en el administrador termina siendo un colador con huecos entre los items visibles y lo del otro idioma a ocultar.

Y chau.