Proyecto Real: Podcastvery.com, Frontend y SEO

 Hola, bienvenido o bienvenida otra semana más aquí al podcast de Drupalizate, donde te voy comentando cosas que salen en Drupal o cómo gestiono yo proyectos en Drupal. Esta semana sigo con lo de explicar proyectos reales míos, proyectos personales que no de clientes, y digamos que explicar cómo están hechos por dentro y las decisiones que me ha llevado a hacer determinadas cosas de cierta forma, que en algunos casos no tiene por qué ser la mejor, pero voy a comentar los motivos que me han llevado a eso. Hoy voy a hacer la presentación y comentar algunas cosas de SEO o de Frontend mejor dicho, o sea Frontend SEO, del proyecto que es podcastvery. Lo habéis visto en el título del episodio que es podcastvery.com. Igualmente dejo el link en las notas del programa. Hoy toca presentación y sólo Frontend SEO porque en el siguiente episodio seguramente mi idea es hablar de Serjapi y después en el siguiente del siguiente tocaré hablar de tema de migraciones y gestión de datos. Y esto es porque, explicando ya un poco de lo que va este proyecto, este proyecto la idea inicial era coger datos Open Data, o sea datos abiertos, en este caso de podcast, una base de datos que en este caso son Postgres, que digamos hay un Podcast Index y creo que ya lo comenté en Webicaster porque esta idea del negocio también vino un poco, perdón, del negocio, del proyecto, vino un poco de Webicaster, que es otro proyecto que ya comenté en el episodio anterior, donde ya estaba cogiendo una base de datos Postgres de Podcast Index.org. Es un servicio gratuito que te dejan descargarte su base de datos. Hay varios contenidos pero el interesante en mi caso es la URL de los podcast. Tienen cuatro millones y pico de podcast. En Webicaster indexo la URL y cuatro cosas más, base de estadísticas. En Podcast.BD cojo esa URL y para cada URL digamos que voy a escrepear los contenidos del podcast y cojo todos o casi todos los contenidos de cada uno de los podcast. En vez de hacerlo de cuatro millones y pico ya lo intenté filtrar en un inicio para que sólo fueran de un millón y pico, filtrándolo sobre todo por idioma y por cantidad de episodios más o menos, porque también digamos que esa base de datos está un poco desactualizada y la cantidad de episodios reales no corresponde siempre, pero al menos es para no tener cuatro millones de páginas en Drupal, pues cada una de esas URL de podcast en Drupal las estoy traduciendo a un nodo, una página en Drupal, pues en vez de tener cuatro millones de páginas, de momento la idea era empezar con un millón y pico que son básicamente los podcast en inglés y los podcast en español, porque vi que me estaba quedando muchos podcast en otros idiomas que no valían la pena, y también muchos podcast en este caso que tenían muy pocos episodios con lo cual el caso de uso de este proyecto de juguetear mucho con temas de búsquedas y con gran volumen de datos también empezamos por las partes más simples en un caso, y si veían de que esto podía, era factible ampliarlo, pues ya quitaría el límite y cogería los cuatro millones y pico de podcast. Bueno, que me estoy alargando mucho con esto. Se coge una base de datos Postgres externa, la meto en mi local o en el servidor de producción, o en mi caso la metí en local primero, después lo volví a ejecutar con una copia más nueva en producción, cojo esas URL y las creo en Drupal en formato nodos, y esos nodos después tengo código custom que lo que me hace es ir a esa URL coger los datos de esa URL y el título de descripción, autor, frecuencia, episodios, todo lo meto en el nodo en Drupal. Así que hasta aquí lo que es importación de contenidos, como digo, un episodio más concreto explicando con todo lo que me he contado, pues para que se entienda, un gran volumen, una gran tarea de este proyecto es volumen de datos de importación de datos, en este caso con un código custom que decidí no hacerlo con Migrate ya expliqué en episodios futuros por qué. Y la otra gran parte es tema de búsquedas, no quería solo instalar un setjapi y ya está, sino que quería hacer un poquito más y ver hasta donde podía yo llegar con setjapi y elasticsearch, que también me gustan mucho más elasticsearch que solar, esto creo que ya lo comenté en el episodio de aviso, y que ya juegue con setjapi y mapas, en este caso me he enfocado más en temas de texto y búsquedas recomendadas y similares de podcasts, o sea, recomendaciones de podcasts similares. Dicho todo esto, ¿qué requisitos había en este proyecto? Pues esto, leer una gran cantidad de podcasts, o sea, de tener datos, permitir una búsqueda muy simple y facetada, también que tened facets, pues sobre todo recalcado del tema de búsqueda simple y recomendaciones de podcasts similares que es en base de texto, o sea, cómo hacer buenas recomendaciones en base de texto. Después había un requisito que también era menor, pero era que el login y registro de usuarios fuera lo más simple posible, con lo cual se optó, aparte de tener el típico login y registro de usuarios de Drupal, que es un formulario, se optó por instalar el módulo, creo que de demodia, creo que era el social auth, y después había otro sub-módulo que era el social auth de Google, que te permitía básicamente loguearte con tu cuenta de Google. Este mismo módulo, también hay la versión en Twitter, que lo usé para otro proyecto, y realmente a mí como usuario, no como programador, sino como usuario, me molesta mucho menos, o es mucho más fácil usar el de Google que el de Twitter. El de Twitter, si tienes varias cuentas, estás logueado en varias cuentas, es un caos hacer login con el módulo este de Twitter. Con el de Google la verdad es que va todo muy bien, así que si tienes algún proyecto donde os hace falta permitir login con redes sociales, con Twitter por ejemplo, o con Google, en Drupal es muy simple de implementar esto, y como todo es gratuito, o sea en el sentido de que el módulo es contribuido y es gratuito, esto no es como WordPress que tienes que pagar plugins aparte. Vale, otros temas. Este proyecto también es laboratorio de pruebas, aunque tampoco tan laboratorio, porque también lo voy a tocar en otros proyectos, pero es con Talwin. En proyectos reales de clientes no he puesto ningún proyecto real Talwin. En proyectos reales míos, sí, porque como puedo hacer pruebas, y si sale mal o tal, pues son proyectos míos, vale, pero en clientes, también por temas de costes y de agencias con las que trabajo, acostumbran a trabajar con Bootstrap. Dicho esto, yo creía, me forcé a mí mismo a que este proyecto fuera todo con Talwin. Aprovecho esto para comentar que Talwin, para quien no sepa de qué va, básicamente es intentar meter todas las clases posibles, o sea te da unas clases predefinidas, en plan de M-4, pues es el margen con el parámetro 4, o M-1 o M-16, vale, o sea al final juegas definiendo las clases directamente en el HTML. No tienes que picar CSS, o SASS, o LESS, sino ya te da las clases y aperechas, que son bastante simples de usar, o sea, OBS or hidden, por ejemplo, o el margen, o el padding, o display block, por display block es block, tal cual, es una clase, ya la tienes hecha, la tienes que poner solo en tu HTML. Con lo cual te ahorras picar, digamos, el CSS, o SASS, o LESS. El problema con esto es que has de tener muchas, pero muchas, o sea muchísimas plantillas, en este caso en Drupal son Twig, que subescriban todos los valores que te da Drupal por efecto en sus plantillas, o sea tienes que tener plantillas para cada uno de los inputs de los formularios, plantillas para cada uno de los formularios, plantillas para cada uno de los nodos, plantillas para cada uno de los viewmodes, tienes que tener plantillas que subescriban todo cómo se comporta Drupal en el frontend, lo cual, digamos que tiene sus partes malas. Sus partes buenas es de que si controlas bien, o entiendes bien cómo funcionan las plantillas en Drupal, es muy simple de usar y es muy escalable y no te pisas, en mi caso solo trabajo solo en directos personales, pero si trabajas con otra gente le veo mucho potencial porque no te estás pisando constantemente con otra gente, siempre que sigas, digamos, unas normas prestravesidas. Para quien no sepa cómo va el tema de las plantillas en Drupal, Drupal tiene un sistema de plantillas muy potente que te permite sobrescribir y dar sugestiones de posibles subescrituras. Eso significa, por ejemplo, que si, a ver cómo digo, tenemos una plantilla que es node, ¿vale?, que afecta a todos los nodos. Tú en tu tema puedes crear otra plantilla con el mismo nombre que va a sobrescribir a la que viene por defecto en Drupal. O sea, a final la que tengas en tu tema siempre tiene la prevalencia, siempre se usa antes que no la que viene por defecto. Pero claro, y si yo quiero tener una plantilla de un nodo, por ejemplo en este caso tipo podcast, o otra plantilla de otro tipo de nodo que sería episodios del podcast, por ejemplo, ¿cómo lo puedes hacer? Pues en Drupal es muy simple, básicamente es node, guion, guion, el nombre del tipo de contenido, y por ejemplo sería guion, guion, después el view mode, con lo cual es muy simple tener varias plantillas que vayan sobrescribiendo porque se ven distintas, pues el nodo tipo podcast en la página de detalle, o sea, tener una plantilla distinta que el nodo tipo podcast en los listados, porque es un view mode, pues el view mode teaser, por ejemplo. Aquí todo muy bien porque son las que te da Drupal por defecto. El problema viene cuando quieres sobrescribir plantillas que en Drupal no te permiten sobrescribirlas por defecto. Aquí vienen las sugestiones. Las puedes hacer en código custom en tu propio tema, haciendo sugestiones, que yo he tenido que hacer alguna porque no me sirvían, las que vienen por defecto, por ejemplo con algunos casos de formularios, pero te recomiendo que uses el tweak suggest, es un módulo en Drupal, un módulo contribuido, tweak suggest, te dejaré el nombre o el link en las notas del episodio. Básicamente te hace sugestiones, pues las típicas de gran parte de campos de formularios, de bloques y cosas de estas. O sea, te da más sugestiones de ascribir por defecto en Drupal. Esto ya no es solo para usar el Talwin, sino para cualquier desarrollo en frontend que use mucho las plantillas en Drupal, lo recomiendo mucho. Es instalar el módulo y te hace muchas sugestiones ya predichas, con lo cual te ahorras tener que estar investigando cuáles tienes que implementar. Del mismo modo, como he de jugar mucho con plantillas en este proyecto, también uso el módulo tweak tweak. También dejaré el nombre o el link en las notas del episodio. Te da funciones como por ejemplo renderizar bloques directamente en plantillas tweak, o renderizar formularios, o renderizar entidades, o generar enlaces. Sobre todo esto es muy útil para temas de multidioma, que esta web es multidioma por cierto, y que te permite generar enlaces directamente desde las plantillas tweak. Así que también es un módulo que recomiendo mucho, que te saca de más de un apuro, y para implementaciones rápidas en frontend, yo creo que es muy necesario usar este módulo. Después, esto ya es más para temas de deseo un poco, tema de metatags. En este proyecto, pues lo de siempre, se puso un módulo metatags, se configuró para que cada tipo de contenido tuviera sus metatags propios, y también en este caso en los podcasts, pues que cada podcast tuviese su imagen en el oje de image, para que cuando se comparten redes, por ejemplo, pues se vea la imagen de la portada del podcast. Esto es un módulo que es bastante fácil de configurar, y se recomienda mucho por temas de deseo básicamente, y de compartir en redes sociales que se vea correctamente. Sobre todo por esto, las típicas de oje de image, o cuando se comparte por twitter, que se vea en formato cart, el título, una pequeña descripción, y la imagen siempre toca. Comentando esto de imágenes, una cosa en este proyecto, es que no estoy usando los estilos de imagen de Drupal, ni los responsive, ni los no responsive, no uso estilos de imagen, estoy usando la imagen original, entre comillas. Y me digan, esto está muy mal, sí está muy mal, lo sé. ¿Por qué hice esto? Pues porque si tengo un millón y pico, y posibilidad de que en un futuro decida que tenerlos todos, los cuatro millones de podcasts, si cada podcast, no, cada podcast no es el sí, no, cada podcast tiene una portada, tiene una imagen. Por recomendación de Apple Podcast, que digamos que es Dios el que manda sobre el mundo de podcasting, la recomendación de Apple Podcast es que las portadas sean de 3000x3000 píxeles. Así que casi todo mundo que sube una imagen de su podcast, la sube a tamaño 3000x3000. Esto es una burrada. En mi caso es cuando yo importo las imágenes, las estoy importando, escalando, y guardando, creo que quedan en 400 o menos píxeles de ancho por alto. Y esa misma imagen es la que uso en todas partes, como imagen en tamaño original. ¿Por qué? Pues si tengo un millón y pico de podcasts, y estoy generando estilos de imagen, imagínate cuatro estilos de imagen distintos, estaré teniendo en mi servidor un directorio con muchísimos estilos de imagen, que uno sea de 200 píxeles de ancho, el otro sea de 400, y el otro sea de 300 y pico, o de 100 píxeles para el ToonMate. En este proyecto en particular, viendo que tendría tantos nodos con tantas imágenes, y intento limitar el coste del servidor lo máximo posible, dije, en mi caso no tiene ningún sentido, ocupar tanto disco, generar tantos estilos de imagen, prefiero tener solo uno que ya he escalado a un tamaño razonable, desde el punto de vista de que si en original 3000, pues ha alogado a unos 400 píxeles en vez de 3000, una calidad más que suficiente para este proyecto. Eso sí, en móvil o en escritorio se va a ver la misma imagen, lo cual por SEO no es lo mejor. Pero como digo, en este caso, en concreto en este proyecto, por temas de presupuesto, me impuse en el mismo de no, no, voy a usar el tamaño original, entre comillas, o sea, no voy a usar estilos de imagen. Eso lo comento porque no siempre, digamos, en la mayoría de casos sí es recomendable usar estilos de imagen, tanto de responsive como estilos normales de imagen en Drupal. En determinados casos puede ser necesario plantearte si realmente te hace falta para tu caso de uso. Lo más típico sería si es una internet este proyecto y no tuviera, no fuera una web indexable en Google, te traía completamente igual esto. O sea, puedes usar directamente la imagen por defecto sin ningún problema. Por ejemplo, temas de escuelas o temas de museos, internet, es que realmente no haría falta tanto estilos de imagen como mucho uno o dos o ninguno. Bueno, lo comento más que nada para que lo tengáis en cuenta, para que no siempre hagas, no estás obligado siempre a usar estilos de imagen en Drupal. Y después que me dejó esto, ah, y el tema de sitemap. Al tener tantas urls, me pasó similar con Babiso, aunque con Babiso no fue tan exagero. Babiso para quien no haya escuchado el episodio de hace como tres semanas, creo que fue, que es también una web en Drupal que indexó ofertas de empleo de otras webs, y tenía muchísimas ofertas de empleo. La ventaja es que las iba eliminando cada ciertos meses para tener la base de datos un poco controlada en tamaño. Pues también tuve problemas allí, de que al final el sitemaps, que es un XML con todas las urls de tu web, para temas de SEO que Google las encuentra todas y te das indexes, ya tuve algunos problemas, aunque el módulo simple sitemap, simple barra baja sitemap, ya pone también el link en las notas del episodio, es muy simple de configurar y sirve perfectamente. Si que es verdad que cuando tienes muchas, muchísimas urls, tiene un problema de rendimiento un poco... o sea, funciona bien, pero la tarea cron encargada de generar las urls, digamos, es una tarea cron muy pesada. Sobre todo porque en mi caso estoy haciendo auto, o sea, automáticamente estoy actualizando el nodo cada cierto tiempo, y cada vez que se actualiza el nodo, se dice de que el sitemap se tendría que actualizar, por si la url hubiera cambiado o por el contenido supuestamente ha cambiado, y se indica a Google de A, que es la fecha de actualización que vuelve a indexar esto, que ha cambiado el contenido. En este proyecto estoy viendo de que, estoy pensando, aún no lo he hecho, de desactivar el sitemap para las páginas de podcast. Primero porque por lo que he investigado, que yo no soy ningún experto en SEO, es que al tener tantas urls es perjudicial. O sea, al final Google interpreta que tienes un límite de páginas a indexar, sobre todo si es una web nueva, así que si tienes de golpe un millón de urls, Google va a decir postreindexo solo las, me invento, las 100 mil primeras o las 10 mil primeras. Las otras tantas que tienes, ni puñetero caso. Quizá tiene más sentido indexar las páginas importantes, relevantes, por ejemplo este proyecto también tiene lo que son listas de podcast, que son que usuarios pueden dar de alta páginas y hacer recomendaciones o agrupaciones de podcast, por llamarlo de alguna forma, y tiene más sentido quizá priorizar la indexación de estas páginas, que no que se indexen todos los podcasts. Y aparte, como digo, por problemas de rendimiento, de que el cron no da abasto a regenerar constantemente el sitemap. Y que también tiene un peso en base de datos, creo que tenía 2 gigas en base de datos solo de la tabla del sitemap. Y aquí llegaremos a otro punto también para la próxima semana, porque ya me he alargado un poco con este episodio, de que actualmente, a día de hoy, tengo más de 200 gigas en base de datos en MySQL. Cosa que está muy mal, pero en el episodio de la semana que viene, en ese momento, os voy a comentar por qué tengo tantos datos y me voy a cargar un poco en Drupal, porque es problema, digamos, de base, de cómo funciona Drupal y como, también problema mío, de cómo implemente y por qué, que no pensé suficiente si valía la pena indexar todo esto como nodos o no. Así que atento la semana que viene, porque voy a hablar de temas de, pues, esto podemos hacer un poco despacio, y cómo, de 200 y pico de datos, cómo se gestiona todo esto en SETJAPY y cómo podemos tener unas búsquedas relevantes y qué problemas me he encontrado yo con tal tamaño de datos con SETJAPY. Así que atento la semana que viene. Chao.