Entradas con la etiqueta “php”

Filtrar por fechas recientes con MySQL sobre Codeigniter

12 de agosto, 2011 - por | | Desarrollo

Nos pierde lo que acaba de suceder. Vivimos más intensamente lo que es reciente.

Hace poco he tenido que desarrollar el clásico grupo de filtros en forma de checkboxes, combos y radio buttons que se van aplicando con cada click que hace el usuario sobre un listado inicial de todos los elementos posibles.

Uno de los filtros tiene el siguiente aspecto:

La forma más fácil de desarrollar este filtro la encontré utilizando la función MySQL DATE_SUB(). Esta función tiene la siguiente sintaxis:


DATE_SUB(date,INTERVAL expr type)

donde date es una fecha cualquiera válida, y INTERVAL el número que quieres sustraer.

Lo que hice fue lo siguiente. A cada una de las opciones del filtro le asigno un valor numérico (31, 7 y 2 respectivamente). Considero date como el día de hoy, es decir, el momento en el que el usuario está aplicando el filtro. Le paso ambos argumentos a la función de MySQL, en la forma en el que Active Record de Codeigniter permite hacer este tipo de cosas:


$where = "upload_ts > DATE_SUB( NOW( ) , INTERVAL " . $days . " DAY)";
$this->db->where($where, null, false);

Instalar SSH2 para PHP 5.3 en CentOS

10 de agosto, 2011 - por | 1 comentario | Desarrollo, Sistemas

En el proceso de instalación de SSH2 para PHP 5.3 sobre CentOS hay un primer paso que sigue funcionando igual de bien que anteriormente:


yum install gcc php53-devel libssh2 libssh2-devel

Sin embargo, PHP 5.3 sobre CentOS aún no ha incorporado el paquete correspondiente para:


php53-pear

necesario para manejar la instalación de la extensión SSH2 mediante PECL. Es un bug ya apuntado en el Bugzilla de Redhat, pero que aún está pendiente de resolución.

Hay dos métodos principales para resolver este problema. Uno que consiste en utilizar el repositorio IUS, que ofrece paquetes php53 y extensiones más actualizados, junto con un php53-pear. Si te decides por este método, este post de Eric London te explica los pasos principales (en inglés).

El segundo método consiste en conservar el paquete tradicional php-pear y forzar su actualización mediante los siguientes comandos:


pear upgrade --force Console_Getopt
pear upgrade --force pear
pear upgrade-all

Una vez que tienes instalados los paquetes mencionados, ya puedes instalar la extensión SSH2:


pecl install -f ssh2

Una vez que esté instalada, verás que al final del proceso de instalación te indica como siempre la línea que debes añadir al fichero php.ini:


extension=ssh2.so

Reinicias tu servidor HTTP y compruebas que la extensión está cargada y funcionando:


php -m | grep ssh2

Actualizar WordPress por SSH

10 de agosto, 2011 - por | | Sistemas, Tips

Tenemos que ir más allá de nuestros límites corporales para conseguir muchas cosas.

WordPress incluye desde hace tiempo la posibilidad de actualizar directamente desde el admin tanto el core, como los plugins y los temas. Es decir, los 3 componentes principales. Para nosotros, que manejamos múltiples WordPress, es la forma más cómoda de mantenerlos actualizados.

La lástima es que la interfaz del admin sólo menciona la posibilidad de hacerlo por FTP, cuando en realidad también existe la alternativa de hacerlo por SSH. Lo único que hace falta es que tengas instalada y funcionando en tu servidor la extensión SSH2 para PHP; una vez la tienes corriendo, verás cómo WordPress te enseña en la misma pantalla de actualización la posibilidad de hacerlo por SSH.

Si te mueves en Linux, en la mayoría de las distribuciones recientes instalar la extensión SSH2 para PHP es muy fácil: no te exige compilar nada, como hace unos años. Por ejemplo, para Debian/Ubuntu este post de Kevin van Zonneveld te lo resuelve todo (en inglés).

Ahora bien, si te mueves en CentOS, y te has animado a probar PHP 5.3 sobre esa plataforma, la cosa desgraciadamente se complica un poco. Si estás interesado en ésto, te lo explicamos en este otro post.

WordPress como CMS: identificar subpáginas

9 de agosto, 2011 - por | | Desarrollo

Si te has animado a utilizar WordPress como CMS, un poquito más allá de su foco original de funcionar como un blog, la gestión de las páginas pronto se va a convertir en uno de tus temas habituales de desarrollo.

Cuando empiezas a montar la estructura de información del sitio, y separas los contenidos por áreas, te encontrarás probablemente con la clásica estructura de árbol, en la que hay unas páginas principales de las que cuelgan otras secundarias. Identificar en qué pagina y subpágina se encuentra el usuario te va a venir bien para muchas cosas, empezando por un menú básico que ayude a navegar con más facilidad.

WordPress cuenta con su propia función para determinar en qué página te encuentras:


is_page($page);

pero no con una para determinar la subpágina. En nuestros proyectos solemos utilizar la siguiente:


/**
 * Returns boolean value for checking if the current page is child
 * of a parent page
 *
 * @param int
 * @return bool
 */
function is_subpage($iID = null)
{
        global $post, $wpdb;
        if ( is_page() AND isset( $post->post_parent ) != 0) {
                $aParent = $wpdb->get_row( $wpdb->prepare(
                    "SELECT ID FROM $wpdb->posts \
                    WHERE ID = %d AND post_type = 'page' LIMIT 1",
                    $post->post_parent
                ) );
                if ( is_int( $iID ) > 0 ) {
                        if ( $aParent->ID == $iID ) {
                                return true;
                        } else {
                                return false;
                        }
                } else {
                        if ( $aParent->ID ) {
                                return true;
                        } else {
                                return false;
                        }
        } else {
                return false;
        }
}

La llamamos desde el fichero:


/wp-includes/functions.php

Problemas al guardar la IP en la sesión con conexiones 3G

7 de agosto, 2011 - por | | Curiosidades, Desarrollo

Hace poco me ha surgido un problema para el que en un primer momento no encontraba una explicación satisfactoria. Sobre una aplicación escrita en PHP y que trabaja casi todo el tiempo haciendo uso de sesión, me empecé a encontrar con cierres de sesión inesperados.

Las primeras cosas que pensé fueron problemas de disco (suelen acarrear problemas aleatorios de memoria); errores en un refactor reciente de código que consistía en abstraer muchas llamadas a sesión; y problemas de memoria. Fui descartándolos todos, y me puse a pensar en un problema interno de la aplicación en la forma de gestionar la sesión.

Por ahí no encontré un problema, pero sí la razón de esas pérdidas de sesión. Estaba almacenando la IP del cliente como un valor más de la sesión; creo recordar que lo diseñé así para obtener más seguridad. El problema es que la conexión 3G con la que navegaba, cambiaba la IP constantemente. La aplicación cuando comprobaba que la IP de la sesión no correspondía con la del cliente, la cerraba.

Nginx como proxy de Apache para servir contenidos estáticos

28 de enero, 2011 - por | 3 comentarios | Linux, Sistemas

Si sueles utilizar Apache para tus sitios, estarás acostumbrado a la magnitud de sus procesos: son grandes, muy exigentes con la memoria, y relativamente lentos hasta que son lanzados. Evidentemente, ésto no tiene por qué ser cierto en todos los casos; se puede ajustar bastante para que tenga un comportamiento más liviano, y con el tiempo han ido surgiendo alternativas al modelo tradicional de procesamiento (MPM) que consiguen reducir mucho esos puntos negativos.

Ahora bien, en ocasiones uno quiere o necesita seguir manteniendo Apache en su modo tradicional, en una configuración típica con PHP o Python, por diferentes razones: te puede haber convencido su estabilidad; puede que no quieras sacrificar algunos módulos clásicos (como el mod_rewrite); no encuentras la misma actividad en las comunidades de los servidores alternativos, etc. Nosotros nos hemos visto en esa situación, y hemos encontrado una forma, ya bastante popular, de reducir los aspectos negativos de Apache sin renunciar a sus cosas buenas: utilizar Nginx para servir los contenidos estáticos y dejar Apache para todo lo demás.

Si te animas a probar esta solución (y hay un montón de información en la red para implementarla), te encontrarás con: 1) una reducción sustancial del uso de memoria; 2) un correspondiente aumento de capacidad de cacheo a nivel de disco; 3) mayor consistencia en la separación de las tareas del sistema; 4) un rendimiento más ágil y rápido en el servidor y, por lo tanto, en tu sitio. ¿Se puede pedir más? :)