Bibliografía: Web, mobile, UX, programación [WEB]

 

en elaboración… (2022-05)

 

Última actualización: 2019/07/02 – 22:56.

Listado de libros, documentales y páginas web de referencia sobre web, mobile y programación.
Índice de Contenidos
  1. Libros
  2. Páginas web
  3. Audiovisuales

Bibliografía referenciada según normas APA.
Si la referencia se encontrara también en otra sección de la biblioteca, se indicaría al final con la abreviatura entre corchetes.
Al clicar sobre el título subrayado de una referencia se abrirá una nueva pestaña con información adicional sobre esta.
El icono book-icon significa que dicha referencia cuenta con un post dedicado en giveevig.
El icono ✓ significa que la referencia existe en mi biblioteca personal.

Libroslink

* * * *

Clasificación de la Biblioteca:

[ARF] Artes finales, impresión
[AUD] Audiovisual
[BAS] Conceptos básicos, historia
[COL] Color
[DIB] Dibujo, ilustración, lettering, caligrafía
[EMP] Empresariales, marketing
[FOT] Fotografía
[MAR] Identidad visual, marca
[MET] Metodología, proyección, productividad
[OBJ] Objeto, artesanía, industrial, packaging
[PSI] Psicología, sociología, antropología
[PUB] Publicidad, cartelismo
[SEM] Semiología, señalética, señalización
[TYP] Tipografía y diseño editorial
[WEB] Web, mobile, UX, programación
* * *

Artículos relacionados en giveevig:

· Artículo especial sobre Alberto Corazón

Underscores (starter theme for WordPress)

comenzando-a-trabajar-con-undescores_s-giveevig
Home de underscores, desde la cual generar la base de nuestro propio theme.
Índice de Contenidos
  1. ¿Qué es Underscores?

¿Qué es Underscores? link

Hi. I’m a starter theme called _s, or underscores, if you like. I’m a theme meant for hacking so don’t use me as a Parent Theme. Instead try turning me into the next, most awesome, WordPress theme out there. That’s what I’m here for.

My ultra-minimal CSS might make me look like theme tartare but that means less stuff to get in your way when you’re designing your awesome theme. Here are some of the other more interesting things you’ll find here …

* * * *

giveevig post fotografia diseño ruido ciencia

Cómo cambiar las etiquetas a mostrar en la Tag Cloud

 

en elaboración… (2022-05)

 
Para cambiar la cantidad de etiquetas o tags que se muestran en nuestra sidebar (o donde usemos el widget), tendremos que cambiar algunos parámetros de la función wp_tag_cloud que se encuentra en el archivo category-template.php. Vamos a ver dónde encontrarlo y cómo cambiar lo necesario para personalizarlo a nuestro antojo.

Cambiar el número de etiquetas en la Tag Cloud

Tienes tu flamante nube de etiquetas donde se muestran las temáticas que tratas en tu web, y tras haber redactado un post en el que incluyes un nuevo tag ves que éste no se muestra junto a los demás. Lo primero que puedes pensar es que algo has hecho mal, pero no es así. No hay ningún error. Lo que sucede es que has llegado al límite de las 45 etiquetas por defecto.
Cuando utilizamos el widget Nube de etiquetas (Tag cloud) de WordPress parece ser que por defecto sólo se muestran 45 etiquetas como máximo. Quizá nunca lleguemos a utilizar tantas y por ello no lleguemos a sufrir de esta limitación, pero ¿qué pasa si hemos desarrollado un gran listado de tags con el fin de mejorar la usabilidad de nuestra web? En este caso 45 etiquetas pueden sernos insuficientes. Solucionar este no-problema (realmente sólo se trata de cambiar el valor de una variable) es sencillo. Veamos primero dónde encontrar el archivo necesario.

El archivo category-template.php

Desde la interfaz interna de WordPress no es visible. Deberemos buscarlo en la estructura de carpetas de nuestra web mediante un programa FTP de transferencia de archivos (por ejemplo, FileZilla). La ruta es la siguiente:

/wp-includes/category-template.php

Sobra decir que si no somos muy habilidosos convendría guardar una copia del archivo antes de modificarlo. Abrimos el archivo mediante un editor de texto (Notepad++, SublimeText2…) y buscamos la función wp_tag_cloud mediante un sencillo Control+F. La función comienza de la siguiente manera:
function wp_tag_cloud( $args = '' ) {
	$defaults = array(
		'smallest' => 8, 'largest' => 22, 'unit' => 'pt', 'number' => 45,
		'format' => 'flat', 'separator' => "\n", 'orderby' => 'name', 'order' => 'ASC',
		'exclude' => '', 'include' => '', 'link' => 'view', 
		'taxonomy' => 'post_tag', 'post_type' => '', 'echo' => true
	);

[...]

Cambiar el número de etiquetas en la Tag Cloud

Enseguida descubrimos al culpable de todo esto. El número 45 aparece como valor asociado a la variable number: 'number' => 45. Lo cambiaremos con el valor deseado (siempre que sea de tipo integer). Por ejemplo, podemos poner ‘200’ para cubrirnos aunque si tenemos claro que siempre querremos que se muestren todos, lo mejor es que pongamos ‘0’.

En la función encontramos también otras variables. 'smallest' y 'largest' sirven para definir los diferentes tamaños con los que se suelen mostrar los tags dependiendo del número de veces que hayan sido utilizados. Este efecto es muy popular en miles de blogs y páginas web pero muchas veces los nombres de las etiquetas se muestran demasiado desproporcionados entre sí. Esta puede ser una buena manera de controlarlo.
Para saber más de esta función y conocer los detalles de todas sus variables podemos consultar el Function Reference de la función, en la página Codex de WordPress.
* * *

Artículos relacionados en giveevig:

· Artículo especial sobre Alberto Corazón

Yoast SEO para WordPress: Configuración y Guía Completa

 

en elaboración… (2022-05)

 
Configuración Completa de Yoast SEO¿Cómo realizar una configuración completa de Yoast SEO? Vídeo de la charla de Andy García sobre el menú de configuración del plugin Yoast SEO para WordPress. Nos explica y detalla cada una de las pestañas del panel de configuración, aclarando algunos conceptos mientras cuenta trucos y secretos que puede que no conociéramos todavía.
Reescritura de los title y sus %%variables%%, indexar o no las etiquetas y categorías, analizar el feedback del sitemap creado y conocer su ratio, cómo hacer la transición de un plugin previo (por ejemplo, All in one SEO Pack) a Yoast… son algunos de los temas que se tratan y para los cuales Andy García nos indica el camino por el que podemos partir.

Para saberlo todo sobre este plugin, dos enlaces a modo de Biblia:

Un último apunte: ¿Es el SEO suficiente para que un sitio funcione?
Interesante vídeo-hangout sobre el SEO: errores y soluciones.

* * *

Artículos relacionados en giveevig:

· Artículo especial sobre Alberto Corazón

Malware en WordPress: Cómo arreglar nuestra web tras un ataque

El problema con el que me encontré en esta web aproximadamente hace un mes (año 2012) fue el siguiente: al escribir la url en el navegador, se mostraba una pantalla roja de alerta avisando de que no era un sitio seguro… Además de esto, en los resultados de los motores de búsqueda la web aparecía con la siguiente alerta: «Este sitio puede dañar tu ordenador». ¡Maldición! ¿Qué podía hacer? ¿Cómo había ocurrido esto? Analizo todo lo sucedido hasta su solución final.

Malware en WordPress

Lo primero que hice fue consultarlo con colegas usuarios de WordPress. Para mi sorpresa a dos de los que contacté también les había pasado meses atrás, y en repetidas ocasiones. Lo que sucedía era que, sencillamente me habían hackeado la web. Habían logrado entrar en el archivo .htaccess y habían añadido unas líneas de código que hacían que lo que en principio era un sitio seguro (mi web), redireccionara automáticamente a otros donde se alojaba la infección.

Malware en WordPress: primeros pasos

Para conocer con más detalle las características de la infección había que utilizar Google Webmasters Tools y ver la información que Google recogía de mi sitio en sus revisiones. Los mensajes que daba del portal no eran del todo claros; decía que en el último acceso se había intentado redireccionar a otra url (totalmente ajena) al sitio:

When Google last tested this page, no content was returned from your server. Instead, the browser was redirected to a malicious web page. It is likely that your server configuration has been modified.

Y decía lo mismo sobre un post de la web. La página de Google Webmasters Tools no me daba o, yo no supe encontrar, detalles del código con las líneas que hubieran sido añadidas a mis páginas del servidor. Sin embargo, a uno de mis colegas sí que le daba esta información, diciendo cuál era ese código aunque sin especificar dónde. En este caso me contaron que lo que hizo fue buscar desde el navegador, a través de las páginas de la web, ese extracto de código que según Google Webmasters Tools tenía la siguiente pinta (pongo algunas palabras clave entre paréntesis para evitar crear links):

(iframe) (src)="(http)(2puntos)(barra doble)werolais(punto)tk(barra)68113562(punto)html" width="120" height="300">

Búsqueda exhaustiva del Malware

Pero no encontró nada. Parece ser que lo mejor para esto es descargarse todo al disco local a través de un programa de transferencia de archivos, como puede ser FileZilla y ahí ya ponerse a buscar, porque eso es lo que hay que hacer: encontrar el código insertado para suprimirlo.
Bien. Un buen comienzo para esto es empezar por el archivo .htaccess. No detallaremos mucho las características de este archivo, pues son numerosas, pero diremos que es el archivo donde se detallan los permisos de lectura y escritura de nuestros archivos, entre otros. Para más información acerca del archivo .htaccess podéis visitar los siguientes links: (1) El fichero .htaccess: ejemplos de uso, (2) PDF sobre cómo utilizar .htaccess.

En nuestro caso, a pesar de la pantalla roja de alarma, quisimos entrar a la web clickando en el link «a pesar de todo«. Por sorpresa, la dirección de la barra del navegador había cambiado y había añadido otra dirección por detrás, concretamente:

reltime2012(punto)ru(barra)frunleh(interrogante)9.

Sin embargo no me direccionaba a ningún lado; Firefox me mostraba un mensaje de servidor no encontrado pero… bien podría haber ido a la dirección maliciosa e infectar mi ordenador… Hay que tener cuidado con esto y estar muy seguro antes de dar este paso.

Redireccionamientos en el .htaccess

Como ibamos diciendo, este redireccionamiento nos hizo sospechar que el archivo .htaccess había sido modificado. Y efectivamente, al descargarnos todo el sitio al disco duro y abrir el archivo (como un .txt o por ejemplo, con Notepad++), vimos que no tenía nada que ver con nuestro original.
Borramos TODO el contenido del .htaccess y lo completamos con lo necesario y lo subimos por medio de FileZilla, sobreescribiendo el del servidor, que era el que había sido modificado con malware. Después de esto no sabemos concretamente qué es lo que ocurrió… accedimos a la web pero seguía mostrándose el mismo error. Intentamos acceder a la página de Login (que anteriormente ya lo habíamos intentado, obteniendo la misma ventana roja como resultado) y lo que aparecía no lo tenemos en captura, pero era una pantalla del navegador completamente blanca con el texto en h1 FOUND y seguido un link con la palabra here y que direccionaba a la famosa dirección de reltime2012… Obviamente no le dimos al link, ya que se trataba de la url maliciosa. Seguido volvimos a probar la página principal y nada. Pero después, al de unos minutos, probamos la dirección de Login y se cargó bien. Era un paso. Sin dudarlo nos registramos y entramos en el panel de administrador. Ahora ya estabamos dentro, y sabíamos lo que teníamos que hacer…

Nuevamente dentro del panel de control de WordPress

Actualizamos a la última versión de WordPress, antes haciendo un back up, con el plug-in WP-Security Scan. Después cambiamos el theme. Sí, es una putada, porque perdemos configuración, el CSS… entre otras cosas. Pero no queríamos jugárnosla. Nos habían contado que este problema de la intrusión de malware había vuelto a ocurrir después de todos estos pasos hechos hasta ahora, y que cambiando el theme se había arreglado. No tuvimos dudas. Instalamos otro y eliminamos el que teníamos. De todas formas diremos que no está claro que la infección ocurriera por el theme. Es por esto que no diremos el nombre de éste, para evitar falsas acusaciones.

Después había que cambiar las contraseñas. ¿Cúales? Todas. La de WordPress, la del FTP y hasta las del servidor, que en este caso era OVH. Lo mejor para evitar intrusiones son contraseñas complejas, aunque no sean fáciles de recordar. Apuntarlas y guardarlas bajo llave… Como hemos dicho más arriba, también eliminamos la entrada que Google Webmasters Tools decía que contenía malware. No hay que tener dudas con este tipo de acciones; lo mejor es cortar por lo sano.
Lo cierto es que no lleguamos a dedicarle mucho tiempo a buscar el código malicioso en los archivos que habíamos descargado a local… Como hemos dicho antes, en nuestro caso Google WebMasters Tools no nos indicaba el código encontrado, pero sí que nos pusimos a buscar las palabras iframe, reltime, reltime2012… entre otros. Teníamos en la web links a direcciones maliciosas y, esos links tenían que estar por algún lado. La cantidad de documentos que hay dentro de un sitio es enorme, por lo que la búsqueda puede ser desesperadamente larga… Para evitar esto existe la opción de buscar una misma palabra en todos los documentos existentes dentro de un directorio, buscando también en las subcarpetas. Para esto podemos utilizar el programa NotePad++.

La prueba final: Google, ten piedad…

Una vez que parece que todo está limpio podemos pedirle a Google que nos analice nuestro sitio web. Esto se hace desde el panel de Google Webmasters Tools. Después de todo esto, tocará esperar. En los motores de búsqueda de Google se perderán los primeros puestos, teniendo que ir a la segunda o tercera página para encontrar nuestro sitio. Es el precio que hay que pagar, y por eso conviene que una vez enterados de que nuestra web ha sido atacada, la limpieza de nuestro sitio la hagamos cuanto antes.

Desde la página de WebMasters Tools de Google se nos facilita el acceso a varias páginas informativas y de ayuda, pero los listamos a continuación: (1) Stop Badware, (2) PDF sobre qué hacer cuando nos hackean la web, (3) Guía práctica para hacer frente a las advertencias de malware de Google.

Espera y conclusiones finales

Tras la espera de que Google terminara de analizar nuestra web y nos pusiera de nuevo en circulación, el problema se solucionó. No nos quedó claro cual fue la causa principal del malware. Por la necesidad de encontrar una solución atacamos varios frentes, tal y como especificamos arriba, y con alguno de ellos, o varios, dimos en el clavo. En conclusión, hay que hacer nuestro sitio WordPress más seguro. Conviene cambiar las claves de acceso de cuando en cuando, no mantener el nombre de usuario dado (por favor, quitad admin como username aunque la iluminada de vuestra jefa diga que no es necesario…) y también conviene instalar un código Captcha al inicio de sesión.

Esperamos que este post pueda servir de ayuda para todo aquel que se vea afectado por este problema. Suerte y ánimo.
giveevig post fotografia diseño ruido ciencia