Why You Should NOT Remove Dates from Your WordPress Blog Posts pocket.co/s6PRJ (via @pocket)Pues eso, poned la fecha de publicación.

— jose oliveras (@joliveras) 6 de marzo de 2013

Este artículo y un problema que tuve hace relativamente poco con un trozo de código que reutilicé de un post obsoleto, me han animado a añadir no solo la fecha de publicación si no también la de modificación tanto en los Posts como en los Snipets.

Desde hace una temporada procuro publicar en la web los recursos que uso habitualmente y procuro tener actualizados estos, de esta manera sé que la versión que tengo publicada es más o menos fiable.

Fecha de publicación fecha de modificación

Entre mis Snipets encontrareis mi versión de fecha de publicación de posts para wordpress, si a esto le añadimos le posibilidad de mostrar la fecha de modificación <?php the_time('j \d\e\ F \d\e\ Y'); ?> en wordpress podemos dar toda la información que necesita el usuario para saber lo actualizada que está la información que ofreces.

Mostrando la fecha de modificación

Obviamente, si muestras la fecha de modificación cuando el post no ha sido modificado resulta que das información redundante. La manera más simple de controlar este tema es crear un campo personalizado, que al asignarlo al post muestre la fecha de modificación.

El código quedaría algo así:

<p class="fecha">
    <time datetime="<?php the_time('Y-m-j'); ?>">
        Publicado el: <?php the_time('j \d\e\ F \d\e\ Y'); ?>
    </time>
    <?php if((get_post_meta($post->ID, "modificado", true))) { ?>
        <br />
        Última modificación: <?php the_modified_date('j \d\e\ F \d\e\ Y'); ?>
    <?php } ?>
</p>

Con este código da igual el valor que incluyamos en el campo personalizado, basta que quede asociado al post.

Un ejemplo claro sería la tipica página de inicio con su slider, mediante condicionales podemos cargar solo en la página de inicio la hoja de estilos y el javascript que necesitamos para que el slider funcione correctamente, de esta manera esos recursos no se cargan en el resto de páginas.

Entonces, en el <header> añadimos:

<?php if ( is_page ( 'Inicio' ) ) : ?>  
    <link rel="stylesheet" href="<?php bloginfo( 'template_url' ); ?>/css/slider.css" />
    <script type="text/javascript" src="<?php bloginfo( 'template_url' ); ?>/js/slider.js"></script>
<?php endif; ?>

En el ejemplo vemos como solo en la página llamada “Inicio” se cargarían los dos archivos que necesita el slider, ambos situados en la carpeta del tema.

Veamos otros condicionales aplicables al header para incluir recursos solo donde lo necesitamos:

• Páginas con una template específica asignada
• Páginas con una id o titulo especifico
• Subpáginas de una página
• Si es post_type

Los condicionales no solo se pueden aplicar al header, podemos ahorrarnos plantillas si utilizamos los condicionales. Visita la página que wordpress dedicada a los condicionales en el Codex de wordpress para más información.

Otra de las ventajas, es que podré montar wordpress multisite, sin necesidad de reasignar la ruta de localhost cada vez que cambie de proyecto, en la versión gratuita de Mamp era necesario que localhost apuntase unicamente al directorio del multisite, lo que no me permitía trabajar en otros proyectos a la vez.

Ahora toca configurar alguna de las opciones, como la función de envío de emails para testear registros de usuario y formularios. Y el poder acceder desde otras máquinas al servidor virtual.

Permisos de escritura

He tenido algunos problemas de escritura de archivos, más concretamente con la sincronización de archivos en Dropbox. Al final lo he resuelto cambiando los permisos en Mamp, Ownner: mi nombre de usuario y en Group: www con eso me ha funcionado.

Actualización

Más problemas al instalar plugins en local, cambiando permisos a www tanto en Owner como en Group se me ha resuelto el problema. La solución en este post.

Ahora los comercios acceden a un formulario restringido desde donde me envian los datos que quieren modificar, la idea es que los comercios accedan como usuarios registrados, puedan editar los datos de su cuenta (nombre, contraseña, mail) y actualizar la ficha del comercio (fotos, logotipo, descripción, enlaces a redes sociales, etc….).

Aqui el inconveniente es que wordpress no tiene un gran gestor de usuarios y como yo soy muy cabezón no me apetece usar un Plugin.

En cualquier caso los permisos que me interesaría que tenga cada usuario son muy restrictivos, poder ver y modificar los datos de acceso al gestor y la información de su comercio.

El rol de “suscriptor” que viene por defecto en wordpress, se me queda corto (no permite editar páginas o posts) y el de “autor” se pasa, (no quiero que los usuarios creen entradas nuevas).

Podría darle a los suscriptores el atributo de editar posts, pero la idea de cambiar los permisos por defecto, no me acaba de gustar. Al final he optado (de momento) por dar a los usuarios permisos de autor y mediante la ocultación de los menús en el panel de control evitar que puedan crear entradas nuevas, consultar los comentarios o ver las entradas del blog.

Hasta ahora los usuarios pueden loguarse y acceder tanto a su cuenta para cambiar sus datos como a la ficha de su comercio para editar los datos. Lo que me queda es organizar el backend para que al usuario le sea muy fácil actualizar la ficha, ahora mismo está todo en Html, que a mi ya me vale, pero creo que para el cliente le sería mucho más fácil si monto con metabox los campos de la ficha (telefono, web, facebook, twitter, etc…). Obviamente necesito montar también página de ayuda para los usuarios.

Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more. It’s translated to well-formatted, standard CSS using the command line tool or a web-framework plugin.

Reticencias

Había varios motivos por los que me resistía a ponerme a ello, el primero era la pereza de aprender un nuevo “lenguaje”, no tenia claro el tema de la sintaxis, no quería perder la referencia de escritura del Standard Css.

La instalación se realiza por terminal, aquí ya la cosa se me ponía cuesta arriba, nunca he sido amigo de lineas de comandos.

Scss que no Sass

Al fina, lo de siempre, si todo el mundo lo usa, será por algo.

Scss es una de las sintaxis que soporta Sass y aquí vino mi salvación. No es necesario volver a escribir los archivos Css para disfrutar de las ventajas de Sass. Si tu archivo Css lo guardas como Scss y lo compilas puedes hacer una migración relajada de todos tus sites a Scss.

Trabajar modularmente

Aún estoy en proceso de aprendizaje, yo soy de esos de los que hasta que no entienden una parte no pasan a la siguiente (Compass tendrá que esperar).

La mayor ventaja que, de momento, le veo a Sass es poder trabajar modularmente. Puedo dividir mis archivos en cómodos modulos, puedes crear tantos archivos como quieras, el resultado es un único Css, comprimido si quieres.

Un ejemplo:
plantilla.scss + tipografia.scss + botones.scss = style.css

Ahora estoy en proceso de encontrar una formula para dividir la Css en pequeños fragmentos y que la estructura no se convierta en una locura a la hora de buscar el código para editarlo. De momento divido los archivos como:

• var.scss – Para las variables de Sass
• generico.scss selectores html, reset y código comun a todo el site
• menus.scss los menús del site y links de navegación
• formularios-botones.scss campos de formulario y botones
• paginas.scss codigo específico para ciertas páginas

Eventualmente, si el site se complica y está montado en wordpress añado algún archivo más.

• wordpress.scss clases propias de wordpress por ejemplo .gallery o .alignright y .alignleft
• blog.scss todo lo referido al blog y páginas dependientes, categorías, busqueda, etc
• sidebar.scss los sidebars repartidos por el site gestionados por widgets
• comentarios.scss la css de los comentarios puede llegar a hacerse especialmente larga en algunos casos

La verdad es que la experiencia de momento es muy positiva, ya os iré contando.

• El campo de búsqueda se muestra en todas las páginas.
• En el pie ahora están separados los links a las redes sociales y los feeds.
• Ahora los trozos de código ya no se corta, ni salta a la siguiete línea, esto podía dar problemas al copiarlo en algunos navegadores, e optado por añadir scroll si el código es más largo que el contenedor.
• Se ha añadido una navegación por categorías en el apartado de Recursos, para los Snipets.
• Nuevo apartado de Lecturas recomendadas en Recursos, que espero vaya creciendo.
• Web responsive, aún en fase de test.

Por detrás

Pensando en poner en mi web todos los recursos que uso habitualmente … para no ir buscando a lo loco entre carpetas y favoritos.

— jose oliveras (@joliveras) 19 de diciembre de 2012

Me he propuesto colgar todos los recursos que uso habitualmente en esta web, para lo que he tenido que modificar parte de la estructura de plantillas para hacerla más flexible y poder albergar más contenido en cada sección.

Mejor publicado que perfecto

Sigo, poco a poco, migrando la CSS a SCSS. Me está llevando trabajo ya que aprovecho para eliminar código obsoleto que arrastraba de otras versiones. El pasar la CSS a varios archivos para trabajar de forma modular ayuda a localizar todo el código que sobra.

También me queda acabar de reducir archivos de la plantilla usando condicionales.

.cuatro-columnas{width:25%;}
.cuatro-columnas-2{width:50%;}
.cuatro-columnas-3{width:75%;}
.cuatro-columnas-1-3{width:33.66%;} /* 1/3 de cuatro columnas*/
.cuetro-columnas-2-3{width:66.66%;} /* 2/3 de cuatro columnas */

El gran incoveniente es su soporte en Explorer 7, casi todo el tiempo que ahorras en el montaje de la estructura lo pierdes parcheando para IE7. Hace unos días descubrí el proyecto de Christian Schaefer en Github que da soporte a Explorer 6 y 7.

Y aunque soy de los que piensa que no es aconsejable sobrecargar a los navegadores antiguos para que soporten funcionalidades de navegadores más modernos, vale la pena implementarlo para evitarse dolores de cabeza.

He añadido a mi lista de Snipets la implementación para wordpress de box-sizing-polyfill, añadís el Snipet a functions.php, modificando la ruta si es necesario, descargais el archivo de Github y listo.

Una manera de mantener columnas de diferentes alturas alineadas y evitar que se colapsen, es mediante el pseudoelemento :nth-cild, simplemente se trata de añadir clear:left; a la primera columna de cada fila.

En este caso, 3 columas, sería:

li:nth-child(3n+4){
    clear:left;
}

De esta manera, además de igualar las columnas, también forzamos el numero de columnas (3) aunque el ancho del contenedor sea más grande que la suma de las columnas.

Como el cálculo de :nth-child puede resultar algo lioso os dejo el enlace a la herramienta que css-tricks tiene en su página. :nth Tester.

En Explorer … la versión 8 y anteriores no lo soporta. La única solución que se me ocurre es dar una altura minima a cada columna min-height:200px; que contemple la altura de la columna más alta.

Código y ejemplo

Dependiendo del navegador al copiarlo y pegarlo los saltos de linea desaparecian, un engorro.

He intentado solventarlo mediante Html, añadiendo <br /> al final de cada linea de código. También lo he intentado añadiendo <span> a cada linea de código y con display:"block" para forzar los saltos de linea, pero lo que funcionaba en un navegador no lo hacia en otro (Firefox y Safari).

Al final, he encontrado la solución con white-space:pre;

code{white-space: pre;}