Comentarios anidados por defecto en WordPress Posted: 04 Jun 2012 03:04 PM PDT Nada más instalar WordPress encontrarás que hay ajustes que ya están marcados por defecto, desde ajustes generales hasta de incrustación de medios, y como siempre digo en los cursos WordPress, la configuración por defecto tiene mucho sentido, salvo el detalle de los enlaces permanentes y alguna otra cosa, esta si menor. Pero la verdad es que hay un ajuste por defecto que creo que viene mal, y es el de los comentarios anidados, que por defecto vienen desactivados, al ser una característica introducida hace relativamente poco y que antes los temas no soportaban.  Pues bien, si quieres que los comentarios por defecto sean anidados, para provocar conversación y facilitar las respuestas a comentarios concretos, solo tienes que tirar de tu plugin de funciones, añadir lo siguiente y activarlo (o tu cliente) en primer lugar para que este ajuste siempre esté como debe: // activar comentarios anidados por defecto function enable_threaded_comments(){ if (!is_admin()) { if (is_singular() AND comments_open() AND (get_option('thread_comments') == 1)) wp_enqueue_script('comment-reply'); } } add_action('get_header', 'enable_threaded_comments'); Quizás pienses que es mucho código para sustituir a simplemente marcar una casilla de configuración, pero si tienes que instalar muchos WordPress un plugin de funciones con este código te ahorrará horas de clics. |
TimThumb: Problemas y soluciones para desarrolladores de temas WordPress Posted: 03 Jun 2012 04:03 PM PDT  TimThumb es un script PHP que redimensiona imágenes de manera dinámica, a menudo incluido en temas y plugins WordPress. Guarda una cache de las imágenes procesadas por razones de rendimiento en su carpeta de cache por defecto, llamada cache, situada a un nivel de carpetas por encima del mismo script. Afortunadamente, TimThumb permite al usuario definir un directorio de cache personalizado con una constante (FILE_CACHE_DIRECTORY ) así como un mecanismo para cargar su configuración personalizada (un archivo opcional timthumb-config.php ). Esta configuración facilita un montón de flexibilidad a la hora de usar TimThumb en una web de un cliente. Pero cuando TimThumb viene incluido en un tema o plugin este método de configurarlo no es muy útil. Un ejemplo es WooThemes, que usa TimThumb en todos sus temas, o Elegant Themes (mi preferido), que también los usaba aunque lo está abandonando. Y es que hay situaciones en que el servidor no te permite escribir en subdirectorios de tu carpeta /wp-content/themes/ , y en estos casos no te queda otra que usar la localización de la cache por defecto. El problema es que no hay manera sencilla de solucionar esto de una manera global, que sirva para todos los casos. Crear una carpeta /cache/ en cada uno de los directorios de estos temas y cambiar los permisos (chmod) de los mismos no siempre es posible, aunque siempre hay algún sitio donde subir archivos y que, por defecto, normalmente siempre tiene permisos de escritura del servidor: wp-content/uploads y wp-content/blogs.dir Configurando TimThumb para poner su cache en uno de estos lugares es difícil de lograr de manera global. La solución obvia sería crear un archivo timthumb-config.php en cada uno de los directorios del tema en cuestión. Esto no es lo mejor, porque significa que si actualizas un tema todas las personalizaciones y modificaciones tendrías que volver a hacerlas. Una posible solución, más limpia, sería crear un archivo timthumb-config.php centralizado, en wp-content ,por ejemplo, que contenga una sola línea: <?php define( 'FILE_CACHE_DIRECTORY', dirname( __FILE__ ) . '/blogs.dir/1/timthumbcache/' ); ?> De todos modos esto sigue siendo un apaño, que no dirá mucho de ti como desarrollador. Hay otras cosas que puedes hacer en un caso como este: - Deja de poner una copia de tus utilidades compartidas (el “framework”) en cada carpeta de tema. Esto suele ser así porque se piensan los temas para instalaciones en un solo sitio, pero crea un montón de problemas en redes multisitio que ofrezcan distintos temas a sus usuarios, donde un simple cambio en el framework significaría actualizar todos los temas, lo que se convierte en un auténtico dolor de cabeza si el actualizador automático del desarrollador del tema no funciona correctamente. Debes permitir que tu framework se instale como un plugin de red multisitio, o al menos ponlo en la carpeta wp-content. Mejor aún: puedes seguir metiendo los archivos del framework en los temas, pero cárgalos solo si la versión “pluginificada” no está disponible. Esto ofrece lo mejor de ambos mundos.
Ahora bien, en el caso de TimThumb, esta configuración no resolvería el problema. Pero significaría que tendrías que modificar solo un archivo, en vez de 50 en toda la instalación.. - Pon un wrapper alrededor de TimThumb, para que sea más flexible en cuanto a la ubicación del fichero de configuración. Por ejemplo, crea un archivo llamado
mitema-thumb.php , que sería algo así: <?php if ( file_exists( dirname(__FILE__) . '../../global-timthumb-config.php' ) ) { require( dirname(__FILE__) . '../../global-timthumb-config.php' ); } // Load the out-of-the-box TimThumb utility require( dirname(__FILE__) . '/thumb.php' ); ?> Luego apunta todos los atributos src generados por TimThumb a mitema-thumb.php , en vez de directamente a TimThumb. De este modo, si hay una configuración global, se carga la primera, y en caso contrario ya recurrirá al archivo local timthumb-config.php , como especifica TimThumb. - “Pluginifica” TimThumb antes de usarlo. En un mundo perfecto tendrías la flexibilidad de WordPress aplicada a TimThumb: la posibilidad de almacenar la ubicación de tu cache en la base de datos, por ejemplo, o de filtra la ubicación usando
apply_filters() . Eso si, esto genera mucha sobrecarga, pues TimThumb usa unos 700Kb para cargar una sola imagen. Cargar WordPress usando la constante SHORTINIT (que carga solo para que WordPress pueda hacer cosas como get_option() y apply_filters() ) consume 3.500Kb, o lo que es lo mismo, 5 veces más de lo que consume cargar la misma imagen usando solo TimThumb. Esto no sería del todo inaceptable con un sistema de cache potente, pero creo que es mucho sacrificio para un script al que se recurre varias veces cada vez que se carga una sola página. Así que otra idea sería esta: Simplemente recurre a wp-includes/plugins.php . Hay quien dice que un modo de mejorar cualquier paquete PHP es incluir este archivo, y puede que tenga razón. plugins.php es autosuficiente (no necesita del resto de WordPress), y solo añade una sobrecarga de 50 a 100Kb. Así que volveremos a nuestro archivo mitema-thumb.php de nuevo, pero añadiendo algo de la grandeza de plugins.php : <?php // Carga las herramientas del plugin, condicionalmente if ( !function_exists( 'do_action' ) ) { require( dirname(__FILE__) . '/plugins.php' ); } if ( file_exists( dirname(__FILE__) . '../../global-timthumb-config.php' ) ) { require( dirname(__FILE__) . '../../global-timthumb-config.php' ); } // Carga TimThumb require( dirname(__FILE__) . '/thumb.php' ); ?> En este ejemplo, thumb.php no tendría por qué ser una instancia externa de TimThumb. Se puede recurrir al mismo con esas pequeñas maravillas llamadas do_action() y apply_filters() . De este modo tu archivo global-timthumb-config.php o timthumb-config.php no definirá solo constantes, sino que tendrá a su disposición funciones PHP completas, usando la infraestructura de ganchos (hooks) de WordPress. Esto conllevaría mantener un “fork” de TimThumb, pero puede ser un gran recurso para desarrolladores de temas WordPress. Estos fantásticos trucos los encontré en Teleogistic. |
No hay comentarios:
Publicar un comentario