En alguna ocasión me he encontrado con que no puedo hacer update de un proyecto porque SVN indica el error:

Working copy xxxxxxxx locked Please execute “Cleanup” command

Pero cuando lanzao el comando cleanup también devuelve un error:

Cleanup failed to process the following paths: xxxxxx

Con lo que aparentemente, la única solución que queda es hacer un checkout nuevo e intentar no perder los cambios, sin embargo, existe otra solución:

1. Copia los archivos editados en otra carpeta para evitar perder los cambios
2. Borra la carpeta que esté causando el problema
3. Ahora podrás hacer update
4. Copia los archivos editados en la carpeta (no copies las carpetas enteras porque contienen directorios .svn que volverán a darte problemas)
5. Por último, haz commit

Espero os sea de utilidad.

Via | Abstruse Goose

Uno de los errores comunes al implementar Smarty3 es:

Fatal error: Class ‘Smarty_Internal_Wrapper’ not found

Fatal error: Class ‘Smarty_Internal_Register’ not found

Fatal error: Class ‘Smarty_Internal_Template’ not found

Estos se deban, probablemente, a que en tu aplicación estás utilizando la función __autoload también necesaria por Smarty3. La solución a este problema pasa por utilizar la función que PHP nos brinda spl_autoload_register.

En una aplicación, sólo puede existir una llamada a la función __autload, sin embargo, con spl_autoload_register podemos añadir tantos manejadores como queramos y estos se irán ejecutando en el orden en el que los hayamos registrado.

Un ejemplo sencillo de su uso sería:

class AutoloadHandler
{
	static public function launch( $classname )
	{
		print '[['. $name .']]';
	}
}

spl_autoload_register( 'AutoloadHandler::launch' );

new ThisClassNotExists();

El resultado de ejecutar este script sería algo así:

[[ThisClassNotExists]]

Fatal error: Class ‘ThisClassNotExists’ not found in …

El cual nos indica que está llamando de manera correcta al autoload, pero al no estar implementado de manera correcta y no existir la clase ‘ThisClassNotExists’ nos devuelve un error.

En definitiva, para solventar el problema, no será necesario que modifiques el código Smarty, pues este ya está utilizando de manera correcta spl_autoload_register, lo que debes hacer es sustituir tu __autoload por una clase con una función ‘launch’ (llámala como quieras) y registrarla mediante:

<pre>spl_autoload_register( 'MyAutoloadHandler::launch' );</pre>

Si estás utilizando Smarty2 y te has decidido a dar el salto a Smarty3 para aprovecharte de sus nuevas funcionalidades (como por ejemplo la nada despreciable opción de herencia en templates), verás que existen algunas incompatibilidades, por ejemplo, se han decidido por seguir el estandar camelCase en el nombre de las funciones, utilizan getters y setters para los atributos o han cambiado la manera de registrar bloques.

En el caso del popular plugin smarty-gettext, si tenemos personalizada la llamada al traductor con, por ejemplo ‘{t}’ como es mi caso, nos encontraremos con un bonito error:

function call ‘register_block’ is unknown or deprecated

Esto es debido a que la forma correcta de registrar bloques en Smarty3 es:

$this->register->block('t', 'translate');

en lugar de:

$this->register_block( 't', 'translate' );

Una vez hecho esto, el siguiente error que nos deja Smarty es:

Plugin “t” not callable

En lugar del antiguo ‘translate’, el segundo parámetro deberá ser el nombre correcto de la función, es decir ’smarty_translate’:

$this->register->block('t', 'smarty_translate');

de este modo solventaremos el problema y podremos seguir disfrutando de nuestro plugin de traducción.

Antes de empezar a hacer el upgrade de symfony debemos asegurarnos que los plugins utilizados actualmente en el proyecto son compatibles con la versión 1.4, en caso de no ser compatibles, tenemos tres opciones:

1. Buscar un plugin similar que sí sea compatible.
2. Modificar nuestra aplicación para que no utilice dicho plugin.
3. Si no podemos prescindir de él, habrá que esperar a que saquen la compatibilidad o hackearlo nosotros mismos (lo qual podría ser muy fácil o muy difícil en función del tipo de problema).

Pasos a seguir para subir de versión:

1) Update de los canales de pear

sudo pear update-channels

2) Upgrade de symfony a la versión 1.3

sudo pear upgrade -f symfony/symfony-1.3.0

3) Validamos que no estamos usando métodos deprecated (estós están eliminados en la versión 1.4)

symfony project:validate

En caso de obtener errores del validador, los solventaremos antes de hacer el upgrade siguiendo instrucciónes en la página Deprecations and removals in 1.3

4) Upgrade del projecto a la versión 1.3

symfony project:upgrade1.3

5) Upgrade de los plugins a la última versión

symfony plugin:upgrade [plugin]

6) Upgrade de symfony a la última versión

sudo pear upgrade symfony/symfony

7) Limpiamos la caché antes de probar

symfony cc

Ahora deberíamos tener nuestro proyecto updateado a la última versión estable de symfony

Symfony permite varios métodos para internazionalizar nuestra aplicación. Por defecto, utilizan el formato XLIFF sin embargo, personalmente me gusta más gettext.

¿Cómo configurar symfony para usar gettext?

Para configurar symfony para que utilice gettext seguiremos los siguientes pasos:

1) Activamos el módulo I18N modificando el archivo settings.yml:

#apps/<appName>/config/settings.yml
all:
  .settings:
    charset:                utf-8
    i18n:                   on
    standard_helpers:       [ [TUS_HELPERS_ACTIVADOS]..., I18N]

2) Abrimos el archivo factories.yml y añadimos la entrada i18n:

#apps/<appName>/config/factories.yml
all:
  i18n:
    class: sfI18N
    param:
      default_culture:  en_US
      source:           gettext</pre>

3) Crearemos una carpeta i18n dentro de apps//:

apps/<appName>/i18n/<lang>

Donde <lang> será el idioma en dos letras (en, es, fr…) y dentro tendremos los ficheros messages.po y messages.mo.

Ahora podemos utilizar la función __( ‘texto_a_traducir’ ) con doble underscore [ _ ] en lugar del simple utilizado normalmente.

¿Cómo generar automáticamente nuestros ficheros po y mo?

Symfony trae una serie de herramientas que nos permiten generar los archivos po y mo de manera automática. Invocando el comando:

symfony i18n:extract frontend en --auto-save

Se recorrerá todos los archivos php de nuestra aplicación (código y templates) y sacará los textos que encuentre en las funciones __().

También se puede utilizar el mismo comando de la siguiente manera:

symfony i18n:extract frontend en --auto-delete

para eliminar las cadenas de texto que ya no existen.

Una sencilla función que dado un número de segundos, nos devuelve el tiempo en formato hh:mm:ss

protected function makeTimeFromSeconds( $total_seconds )
{
    $horas              = floor ( $total_seconds / 3600 );
    $minutes            = ( ( $total_seconds / 60 ) % 60 );
    $seconds            = ( $total_seconds % 60 );

    $time['horas']      = str_pad( $horas, 2, "0", STR_PAD_LEFT );
    $time['minutes']    = str_pad( $minutes, 2, "0", STR_PAD_LEFT );
    $time['seconds']    = str_pad( $seconds, 2, "0", STR_PAD_LEFT );

    $time               = implode( ':', $time );

    return $time;
}

Espero os sea de utilidad.

Aquí os dejo algo de información sobre como solicitar variables de configuración en symfony además de un listado muy útil con todas las variables que Symfony trae predefinidas.

Cómo pedir variables definidas

Se puede llamar a la función estática get del objeto sfConfig para solicitar cualquier variable definida pasándo dos valores. El primero indica el nombre de la variable solicitada y el segundo, el valor que retornará en caso de no existir dicha variable.

sfConfig::get('sf_config_variable', 'The default value'); // The default is optional

Además de las variables que symfony trea configuradas por defecto, podemos añadir nuestras propias variables. Esto se hace en los archivos app.yml. Tenemos un app.yml global para todas las aplicaciones y módulos de nuestro proyecto localizado en:

/path/to/project/[PROJECT_NAME]/config/app.yml

y otro para cada una de las aplicaciones:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config/app.yml

NOTA! Si existen dos variables con el mismo nombre en el app.yml global y en el de aplicación, este último valor sobreescribirá el valor global.

Para solicitar una variable definida en uno de estos archivos app.yml devemos añadir app_ al nombre de la variable como se muestra en el siguiente ejemplo:

sfConfig::get('app_sf_config_variable');

Si en el archivo app.yml definimos la variable en cascada, como por ejemplo:

all:
  admin:
    email: admin@mail.bla

Deberemos acceder a ella añadiendo los diferentes niveles en la llamada:

sfConfig::get('app_admin_email');
También podemos acceder a los valores configurados en settings.yml añadiendo el prefijo “sf_” al valor que queremos recuperar.

Variables definidas por Symfony Framework

sf_symfony_lib_dir

Path real a la carpeta lib del framework:

/usr/share/php/symfony/symfony12/lib

Project Structure and Layout

sf_root_dir

Path a la raiz del projecto:

/path/to/project/[PROJECT_NAME]

sf_apps_dir

Path a la carpeta “apps” del proyecto:

/path/to/project/[PROJECT_NAME]/apps

sf_lib_dir

Path a la carpeta “lib” del proyecto:

/path/to/project/[PROJECT_NAME]/lib

sf_log_dir

Path a la carpeta “log” del proyecto:

/path/to/project/[PROJECT_NAME]/log

sf_data_dir

Path a la carpeta “data” del proyecto:

/path/to/project/[PROJECT_NAME]/data

sf_config_dir

Path a la carpeta “config” del proyecto:

/path/to/project/[PROJECT_NAME]/config

sf_test_dir

Path a la carpeta “test” del proyecto:

/path/to/project/[PROJECT_NAME]/test/

sf_doc_dir

Path a la carpeta “doc” del proyecto:

/path/to/project/[PROJECT_NAME]/doc

sf_plugins_dir

Path a la carpeta de “plugins” del proyecto:

/path/to/project/[PROJECT_NAME]/plugins

sf_cache_dir

Path a la carpeta “cache” del proyecto:

/path/to/project/[PROJECT_NAME]/cache

sf_web_dir

Path a la carpeta pública “web”:

/path/to/project/[PROJECT_NAME]/web

sf_upload_dir

Path a la carpeta pública de “uploads”:

/path/to/project/[PROJECT_NAME]/web/uploads

Application Information

sf_app

El nombre de la aplicación en la que está el archivo, como por ejemplo “frontend” o “backend”.

sf_environment

Entorno de desarrollo actual como por ejemplo “dev”.

sf_debug

Devuelve el estado actual del modo debug. Puede estar activado “1″ o desactivado “0″.

Application Structure and Layout

sf_app_dir

Path a la carpeta de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]

sf_app_config_dir

Path a la carpeta “config” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config

sf_app_lib_dir

Path a la carpeta “lib” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/lib

sf_app_module_dir

Path a la carpeta “modules” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules

sf_app_template_dir

Path a la carpeta “templates” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/templates

sf_app_i18n_dir

Path a la carpeta “i18n” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/i18n

Cache Structure and Layout

sf_app_base_cache_dir

Path a la carpeta de la aplicación actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]

sf_app_cache_dir

Path a la carpeta de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev

sf_template_cache_dir

Path a la carpeta “template” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/template

sf_i18n_cache_dir

Path a la carpeta “i18n” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/i18n

sf_config_cache_dir

Path a la carpeta “config” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/config

sf_test_cache_dir

Path a la carpeta “test” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/test

sf_module_cache_dir

Path a la carpeta “modules” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/modules

Application Settings

sf_error_404_module

Módulo que ha hecho saltar el error 404.

sf_error_404_action

Acción que ha hecho saltar el error 404.

sf_logging_enabled

Valor boleano que nos indica si el loggin de la web está activo “1″ o no “0″.

sf_escaping_strategy

Valor boleano que indica si la clase sfView está usando Escaping Strategy “1″ o no “0″.

sf_no_script_name

Valor boleano que indica si la aplicación requiere nombre de script.

sf_csrf_secret

La clave CSRF secreta configurada en la aplicación.

También:

Se puede acceder a la información del actual contexto con las siguientes funciones:

sfContext::getInstance()->getActionName();

Devuelve el nombre de la acción actual. También puede llamarse desde los templates con $this->getActionName().

sfContext::getInstance()->getModuleName();

Nombre del módulo actual. También puede llamarse desde los templates con $this->getModuleName().

sfContext::getInstance()->getModuleDirectory();

Path al directorio del módulo actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules/[MODULE_NAME]

Manuel Aguilar publicó una magnífica presentación sobre cómo optimizar aplicaciones Web dada en la PHP Barcelona Conference 2008 y he considerado interesante recopilar a modo de resumen las ideas más importantes de ese artículo, en cualquier caso, recomiendo la lectura del mismo para recoger toda su esencia y ampliar información.

Partiendo de un estudio de Yahoo! que dice que el 80% del tiempo de carga de una web corresponde al lado del cliente, podemos seguir una serie de reglas que aumentarán significativamente la percepción de velocidad del usuario.

1. Aumentar el tiempo de expiración de los elementos cacheados que no varían como CSS o JavaScript: Para forzar la carga de los mismos cuando haya cambios, podemos añadir el md5 del contenido del fichero como parámetro, así el navegador lo recargará cuando cambie el hash. Ej: style.css?hash=f9d35dcf65d8f67e288ae2f12fc069f7

2. No colocar código JavaScript o estilos inline: es mejor colocarlos como ficheros externos fácilmente cacheables, de este modo evitaremos descargar todo el html por un cambio de estilo.

3. Reducir el número de ficheros externos: Los navegadores sólo pueden aceptar dos descargas simultaneas de un mismo dominio, si unimos nuestras librerías JavaScript y nuestros CSS en un único archivo evitaremos dilatar innecesariamente el tiempo de descarga.

4. Usar subdominios diferentes para las imágenes y para los elementos estáticos: Conseguiremos así descargar 8 elementos de manera simultánea y reducir la carga de la web. Si además podemos optimizar un apache aparte para servir las imágenes, conseguiremos un mejor rendimiento al servirlas.

5. Compactar los ficheros JavaScript: Existen programas gratuitos como YUI Compressor que comprimen los archivos JavaScript consiguiendo resultados de hasta el 50%.

6. Utilizar compresión en el servidor: Los servidores modernos como Apache son capaces de comprimir la información antes de servirla, posteriormente los navegadores actuales como Explorer o Firefox la descomprimen de manera transparente al usuario.

7. Fomentar el uso de imágenes con muchos sprites: Estas son imágenes grandes que contienen muchas imágenes pequeñas. Según lo comentado en el punto 3 tardaremos mucho menos en descargar una imágen con 50 sprites que 50 sprites de manera individual. Posteriormente utilizaremos CSS para definir la sección de imágen que se mostrará.

8. Mover los CSS al <head>: Navegadores como Explorer no renderizan la web hasta que no tienen todos los CSS, si los colocas en la cabecera podrá empezar antes a mostrar la web.

9. Mover los JavaScript al final de la página: Hasta que un fichero JavaScript no se ha leido completamente el navegador no continua con la carga. Si los movemos al final de la página este se estará cargando cuando el usuario ya está navegando por la web.

10. Evitar llamadas duplicadas a JavaScript y CSS: Si el navegador encuentra un fichero JavaScript para la carga hasta que este se ha leido completamente, si posteriormente vuelve a encontrar una llamada al mismo JS, volverá a parar la carga hasta que se haya leido.

Vía | Optimización aplicaciones PHP

Hace unos días, os comentaba que es una caché y como entenderla en el marco de la programación web. Para seguir con el aprendizaje de este sistema, he desarrollado una pequeña clase que permite cachear información (strings, arrays, resultados de base de datos, objetos…) en nuestra máquina y descongestionar así el motor de base de datos, por poner un ejemplo.

Lo primero que debemos hacer es pensar en que necesitamos para su correcto funcionamiento, así que, manos a la obra.

Como sabemos, una caché es un sistema al que le pasamos un objeto X y él lo almacenará en su sistema de una manera determinada, por lo tanto, necesitaremos una función que dado un identificador único y unos datos, guardará la información. Además de esto, necesitamos indicarle un tiempo de vida (ttl) a esa información cacheada, sino estaremos devolviendo eternamente el valor almacenado.

Un concepto que nos puede resultar interesante es el de caché de grupo. Imaginemos que tenemos un sistema que va cacheando información de nuestra base de datos; tenemos una tabla user y una tabla user_profile y cacheamos los resultados de ambas tablas por separado. Imaginemos también que por temas de LOPD el usuario solicita que eliminemos todos sus datos de nuestras máquinas, así que eliminaremos el registro de la tabla user y user_profile y procederemos a eliminar el cacheo de los datos de cada tabla por separado. Si tuviesemos agrupada la información de usuario, con una única llamada a la función remove y pasándole el identificador de grupo, eliminará la caché de ambas tablas.

A medida que vaya explicando cada función, os pondré el resultado final para que os hagais una idea de como va quedando el código:

    public function save ( $id, $group_id = 'default', $data, $ttl = self::CACHE_TTL )
    {
        if ( $this->caching )
        {
            $this->set_file_routes( $id, $group_id );

            // If the directory don't exists, I create.
            if ( !is_dir ( $this->file_path ) )
            {
                if ( !mkdir ( $this->file_path, 0777, true ) )
                {
                    return false;
                }
            }

            if ( !is_array ( $data ) && !is_object( $data ) )
            {
                $data = array ( $data );
            }

            // Serialize data for caching.
            $data = serialize ( $data );

            // I get a hash to check integrity in the future.
            $hash = md5 ( $data );

            $meta['expiration_time']    = time () + $ttl;
            $meta['integrity']          = $hash;
            $meta['data']               = $data;

            // Serialize meta info to put in a file.
            $data    = serialize ( $meta );

            return file_put_contents ( $this->file, $data, LOCK_EX );
        }

        return false;
    }

A su vez, debemos poder recuperar los objetos almacenados en un futuro, así que también programaremos una función que dado un identificador y un identificador de grupo, devolverá unos datos get($id, $group_id). El tener que pasar el identificador de grupo en esta función es debido a que las rutas de almacenamiento se generan a partir de ambos identificadores.

    public function get ( $id, $group_id = 'default' )
    {
        if ( $this->caching )
        {
            $this->set_file_routes ( $id, $group_id );

            if ( !file_exists ( $this->file ) )
            {
                return false;
            }

            $meta    = file_get_contents ( $this->file_path . $this->file_name );
            $meta    = unserialize ( $meta );

            $check_expiration   = $this->check_expiration ( $meta['expiration_time'] );
            $check_integrity    = $this->check_integrity ( $meta['integrity'], $meta['data'] );

            // Expiration and integrity control.
            if ( $check_expiration && $check_integrity )
            {
                $data = unserialize ( $meta['data'] );

                return $data;
            }
            else
            // Clean the expired or not correct caché.
            {
                $this->remove ( $id, $group_id );

                return false;
            }
        }

        return false;
    }

Como último elemento fundamental, necesitaremos poder borrar unos datos de la caché en caso de que ya no sean válidos porque se han modificado o borrado, así que crearemos una función que dado un identificador y un identificador de grupo, elimine el objeto cacheado. A esta función la llamaremos remove($id, $group_id).

    public function remove( $id, $group_id = 'default', $group_level = false )
    {
        $this->set_file_routes( $id, $group_id );

        // Don't remove the 'default' group
        if ( $group_level && $group_id != 'default' )
        {
            if ( !$this->group_path || empty ( $this->group_path ) )
            {
                return false;
            }

            return $this->del_tree ( $this->group_path );
        }
        // Check that the file exists and delete the file cached folder
        elseif ( $this->file_path && !empty ( $this->file_path ) )
        {
            return $this->del_tree ( $this->file_path );
        }
        else
        {
            return false;
        }
    }

Como sabemos, la caché guarda los objetos durante un tiempo determinado y una vez ha pasado ese tiempo, el objeto se considera inservible, por lo tanto añadiremos una función check_expiration() que nos dirá si el objeto está caducado.

private function check_expiration ( $expiration_time )
{
return ( time() < $expiration_time );
}

¿Qué pasa si cuando estoy almacenando los datos hay un problema de escritura y los datos se almacenan mal? Podría suceder que los datos almacenados esten corruptos, y todas las devoluciones de dicho objeto fueran defectuosas. Para comprobar que los datos guardados no están corruptos, crearemos una función check_integrity().

    private function check_integrity ( $read_hash, $serialized_data )
    {
        $hash = md5 ( $serialized_data );

        return ( $read_hash == $hash );
    }

Además de estas funciones, crearemos varias constantes que definirán los valores de configuración del sistema como pueden ser el tiempo de vida (ttl) de un objeto cacheado por defecto o el directorio en el que se guardará la caché.

    // Path to cache dir.
    const CACHE_DIR = 'cache/';

    // Max. time to life of this cache.
    const CACHE_TTL = '3600';

    // Extension to use in cache files.
    const CACHE_EXT = '.cache';

En el código se llama a las funciones get_status() y set_status() que sirven comprobar si está activo el sistema de cacheo y habilitar/deshabilitar respectivamente. set_file_routes() crea las rutas en las que se almacenará los datos cacheados y get_key() crea hashes a partir de un identificador. Por último, del_tree() nos ayudará a eliminar un directorio de manera recursiva.

    public function get_status ()
    {
        return $this->caching;
    }

    public function set_status ( $status )
    {
        $this->caching = $status;
    }

    private function set_file_routes ( $id, $group_id )
    {
        $key_name    = $this->get_key ( $id );
        $key_group   = $this->get_key ( $group_id );

        $level_one = $key_group;
        $level_two = substr ( $key_name, 0, 4 );

        $this->group_path   = self::CACHE_DIR . $level_one . '/';
        $this->file_path    = self::CACHE_DIR . $level_one . '/' . $level_two . '/';
        $this->file_name    = $key_name . self::CACHE_EXT;
        $this->file         = $this->file_path . $this->file_name;
    }

    private function get_key ( $id )
    {
        return md5 ( $id );
    }

    private function del_tree ($dir)
    {
        if ( empty ( $dir ) )
        {
            return false;
        }

        if ( !file_exists ( $dir ) )
        {
            return true;
        }

        if ( !is_dir ( $dir ) || is_link ( $dir ) )
        {
            return unlink ( $dir );
        }

        foreach ( scandir ( $dir ) as $item )
        {
            if ( $item == '.' || $item == '..' )
            {
                continue;
            }

            if( is_dir ( $dir . $item ) )
            {
                $this->del_tree ( $dir . $item . '/' );
            }
            else
            {
                unlink ( $dir . $item );
            }
        }

        return rmdir ( $dir );
    }

Puedes descargarte el archivo final desde aquí cache.class.php.

Aunque esta caché es perfectamente funcional, este ejercicio nos sirve para entender un poco más el funcionamiento de un sistema de caché. Si queremos implementar uno en nuestra aplicación, os recomiendo mirar CacheLite (si nuestra aplicación es pequeña), APC o Memcached (si nuestra aplicación es grande y/o con servidores balanceados).