Archivo de la categoría: Programación

Programación

WordPress y Woocommerce, problema mostrando medios y productos con variaciones

Sígueme

lesterfibla

Desarrollador Web y Programador at 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.
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

lesterfibla

Desarrollador Web y Programador at 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.
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.

Usar <? en vez de <?php para los scripts PHP

Sígueme

lesterfibla

Desarrollador Web y Programador at 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.
Sígueme

Estoy actualizando mi manera de trabajar en proyectos de desarrollo web y programación, y una de las cosas que estoy haciendo es configurar XAMPP con hosts virtuales para desarrollar en local.

Todo funcionaba perfecto con pruebas de html estático pero ¡¡Cueeecccc!! todo se fue al carajo cuando probé algunos sitios php. Simplemente no me estaba interpretando el código php :S Muy raro.

Probé primero jugando con los .htaccess y los nombres de los dominios locales y nada.

Finalmente llegué al problema: resulta que desde no sé qué versión de php la configuración por defecto obliga a usar
<?php ?>
en vez de solo
<? ?>

La solución es modificar el archivo php.ini y activar (on) la directiva:
short_open_tag=On

Simple, pero me demoró un tiempo llegar a ello.

Configurar email piping a archivo php en cPanel sin cPanel

Sígueme

lesterfibla

Desarrollador Web y Programador at 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.
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

lesterfibla

Desarrollador Web y Programador at 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.
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

lesterfibla

Desarrollador Web y Programador at 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.
Sígueme

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