Archivo de la categoría: Desarrollo Web

Desarrollo Web

WordPress y Woocommerce, problema mostrando medios y productos con variaciones

Sígueme
Desarrollador Web y Programador en www.lesterfibla.com/pro
Desarrollador y Programador Web de día, VDJ por las noches. Amante de la música, los deportes y los medios de comunicación.
lesterfibla
Sígueme

He estado los últimos días trabajando en una nueva tienda online (OutdoorFeat.cl), sobre WordPress y Woocommerce, y todo iba perfecto: Hice un theme completamente a la medida, intentando usar solo los plugins externos absolutamente necesarios e intentando programar la mayor parte yo mismo.

Todo iba bien. Funcionaba perfecto.

Claro, hasta que apareció un «pero» :(

De un momento a otro (eso creí al menos) en la biblioteca de medios solo me mostraba algunos productos, no todos. Si buscaba algún producto si aparecía, y de todos modos siempre las fotos aparecían sin problemas en el front del sitio. Era solo visibilidad en el dashboard.

Luego, probando hacer un producto con variaciones en woocommerce, se creaban 18 variaciones, pero por algún motivo no se mostraban todas. Solo veía 2 página de 4 variaciones cada una. Faltaban 10 !!!!

Googleé y googleé y solo llegué a algunas preguntas similares cuyo problema era de recursos de servidor. Memoria y tiempos de ejecución. Aumenté ambos por si acaso y nada. igualé otros parámetros a otra tienda online de similares características y nada. Seguía fallando.

En un momento de iluminación, encontré el error. El error fui yo mismo (¿y cuándo no?).

Necesitaba limitar la cantidad de posts a mostrar en el sitio, en las categorías con listados de productos, en los resultados de búsqueda, etc. Así es que hice una función para cambiar el parámetro posts_per_page por defecto:


function limita_posts_default( $query ){
    $query->set('posts_per_page', 4);
    return $query;
}
add_filter('pre_get_posts', 'limita_posts_default');

Y eso era.

Resulta que ese cambio afectaba a todas las queries, y en este caso, aplicaba también al listado de medios en la biblioteca de medios y al listado de variaciones de productos.

Obviamente creo que sería una muy buena idea que los amigos de wordpress separaran algunas cosas entre front y dashboard, pero bueno, es lo que hay.

La solución fue aplicar el límite solo en los casos que fuera necesitando, por ejemplo para el caso de las búsquedas:


function limita_posts_default( $query ){
    if( is_search() ){
        $query->set('posts_per_page', 4);
    }
    return $query;
}
add_filter('pre_get_posts', 'limita_posts_default');

Ojalá a alguien le sirva cuando ande tan perdido como yo andaba,

Cómo solucionar error 404 al usar wp-blog-header fuera de WordPress

Sígueme
Desarrollador Web y Programador en www.lesterfibla.com/pro
Desarrollador y Programador Web de día, VDJ por las noches. Amante de la música, los deportes y los medios de comunicación.
lesterfibla
Sígueme

guia-php-wordpressEstoy usando wordpress solo como backend para manejar el contenido de un sitio, pero en el front no uso todo el sistema de themes, sino que simplemente llamo a wp-blog-header.php al inicio de mis paginas y luego puedo usar las queries que necesito. Este sistema es lo que el mismo codex de wordpress recomienda. ¡Y funciona!!!

Desarrollé todo el sitio y funcionaba todo bien hasta que… :(

…hasta que vi que google no estaba indexando las páginas y que al usar una herramienta online de generación de sitemaps me arrojaba error 404, me decía que la url no existía ¡y yo la estaba viendo!

Pensé en robots.txt, pensé en la opción que trae wordpress para «disuadir a los motores de búsqueda de indexar el sitio», pensé en algún bloqueo vía .htaccess o en algún bloqueo a nivel de servidor Y NADA. Nada funcionaba.

Luego de googlear un rato llegué al problema y a la solución. Resulta que al usar wp-blog-header.php y no existir una url que pueda traducirse en una ruta válida, de algún modo se lanza una cabecera de error 404 a pesar de que todo el sistema siga funcionando bien, y lo más extraño es que solo afecta a algunos navegadores antiguos y a googlebot. Ese era el drama.

Una de las soluciones era «desarmar» todos los llamados que hace por dentro wp-blog-header.php y dejar solo las líneas necesarias, pero parecía ser mucho código para algo tan simple.

La segunda solución que encontré era la más simple, la probé y funcionó. Era simplemente reemplazar

require('wordpress/wp-blog-header.php');

por

require('wordpress/wp-blog-load.php');

Santo remedio. Ahora el sitio se indexa correctamente y no genera esos errores 404 medio fantasmas que había.

Puedo volver a respirar tranquilo.

Configurar email piping a archivo php en cPanel sin cPanel

Sígueme
Desarrollador Web y Programador en www.lesterfibla.com/pro
Desarrollador y Programador Web de día, VDJ por las noches. Amante de la música, los deportes y los medios de comunicación.
lesterfibla
Sígueme

Si bien cPanel nos da la opción de redireccionar una casilla de email hacia un script php (redirecciones de correo > avanzadas), solo permite escribir la ruta a un script pero no nos da la libertad de utilizar otros comandos.

En mi caso, solo escribir la ruta al script php no funcionaba. Se necesitaba agregar explícitamente la ejecución de php y modificar la ruta, y ello no se podía hacer «con pantallitas y botones» en cPanel.

Pues luego de investigar un poco, me conecté vía ssh al servidor y edité el archivo /etc/valiases/midominio.com para poder modificar la línea
prueba@midominio.com: | /home/midominio/prueba-piping.php
y dejarla
prueba@midominio.com: | php -q /home/midominio/public_html/prueba-piping.php

Con eso ya los emails son correctamente entregados al script php.

En una de esas más adelante escribo la manera en que procesé dicha información. Aún estoy investigando y probando al respecto.

Cómo usar pack de lenguajes .phar en osTicket

Sígueme
Desarrollador Web y Programador en www.lesterfibla.com/pro
Desarrollador y Programador Web de día, VDJ por las noches. Amante de la música, los deportes y los medios de comunicación.
lesterfibla
Sígueme

Este último año me he tenido que pelear con dos servidores (de Solution Group y de CDIEC) que si bien no administro yo, he necesitado modificar configuración y pequeños tweaks para hacer funcionar ciertos sistemas. El drama es que ambos son distintos pues sobre un centOS uno tiene un whm/cpanel y el otro tiene un plesk. Pues y he aprendido (por las duras) que aunque el sistema operativo sea el mismo, toda la estructura de archivos y configuraciones varían mucho de un sistema a otro.

En la oficina decidimos probar el sistema osTicket antes de ponernos a desarrollar una solución a medida que gestione las incidencias que requieran soporte, y en este caso el sistema contaba con un pack de lenguaje español que nos facilitaba mucho las cosas… o eso creíamos.

Se instaló el sistema osTicket muy rápido y todo funcionaba perfecto.

Se instaló el idioma español y todo se fue al carajo. El backend simplemente no se traducía y seguía en inglés pero el frontend se iba a blanco.

Me tuve que pasear por mil foros y wikis que poco y nada ayudaban, hasta que llegué a un comentario enterrado por ahí diciendo que había que agregar una línea de configuración para que los archivos .phar fueran utilizables. Y, claro, el pack de penguaje venía en ese maldito bendito formato .phar.

Simplemente había que editar el archivo /etc/php5/cli/conf.d/suhosin.ini y agregar la línea
suhosin.executor.include.whitelist = phar

Muy simple!!!

Pero obviamente dicho archivo NO EXISTÍA EN MI SERVIDOR :(

Buceando vía ssh por toda la estructura de archivos y luego de no encontrar nada, decidí probar agregar la línea en el usr/local/lib/php.ini y milagrosamente funcionó.

Resumiendo

Entonces, para habilitar el uso de archivos .phar en un servidor que utilice whm/cpanel es necesario editar el archivo /usr/local/lib/php.ini y agregar la línea suhosin.executor.include.whitelist = phar (Yo lo hice al final, pero debiese dar lo mismo).

para habilitar el uso de archivos .phar

Espero le sirva a alguien y se ahorre el dolor de cabeza por el que tuve que pasar.

Probando Android

Sígueme
Desarrollador Web y Programador en www.lesterfibla.com/pro
Desarrollador y Programador Web de día, VDJ por las noches. Amante de la música, los deportes y los medios de comunicación.
lesterfibla
Sígueme

Probando la administracion de mi blog desde mi Android (pronto habrá un reporte sobre esa experiencia)

Decir que NO !!! Tenemos que cobrar

Sígueme
Desarrollador Web y Programador en www.lesterfibla.com/pro
Desarrollador y Programador Web de día, VDJ por las noches. Amante de la música, los deportes y los medios de comunicación.
lesterfibla
Sígueme

DineroLeyendo mis feeds (RSS) me topé con un artículo publicado en Maestros del Web sobre dejar de dar asesorías gratuítas o «a cambio de un café»… y me gustó :D

Es super cierto la cantidad de tiempo que se pierde contestando cosas a «conocidos» que están usando lo que uno sabe para sus propios negocios, y uno no gana nada, solo pierde.

Definitivamente hay que aprender a decir que no.

El artículo completo está en www.maestrosdelweb.com/editorial/es-viernes-no-mas-consejos-y-asesorias-gratuitas y acá dejo algunos puntos:

«…las horas que has pasado frente a la computadora, leyendo, creando, peleándote con el código, conociendo el medio tienen un valor, que debe ser reconocido empezando por ti y luego dejarlo claro a los demás. A todos aquellos que quieren aprovechar tu conocimiento para sacar beneficios sin darte nada a cambio, aprende a decirles que «no»…»

«…antes no te daba problemas hacer favores para adquirir experiencia, pero llega un momento en donde necesitamos comprender que los años invertidos en educarnos, aprender y la experiencia tiene un valor económico el cual, tienes todo el derecho de reclamar…»

¿Qué opinan ustedes?

Créditos: Maestros del Web, Stephanie Falla Aroche