Integrar el protocolo OpenGraph en Django

Integrar el protocolo OpenGraph en Django
Photo by MARIOLA GROBELSKA / Unsplash

En el artículo anterior vimos cómo integrar el protocolo Open Graph utilizando Genesis Framework sobre WordPress. En esta ocasión haremos exactamente lo mismo, pero utilizando Django.

La diferencia es interesante.

Mientras que en WordPress fue necesario crear una función, conectarla al hook wp_head y generar dinámicamente cada una de las etiquetas, en Django basta con escribirlas directamente dentro de la plantilla y sustituir los valores correspondientes mediante las variables del sistema de plantillas.

Nota

El propio namespace.mx utiliza este código para generar sus propiedades Open Graph. Puedes comprobarlo consultando el código fuente de cualquier artículo del sitio.

Las propiedades Open Graph

Vamos a utilizar prácticamente las mismas propiedades del artículo anterior.

Algunas siempre tendrán un valor fijo, por ejemplo:

  • og:site_name
  • og:type
  • og:locale

Mientras que otras dependen del artículo que estamos mostrando:

  • og:title
  • og:description
  • og:url

La ventaja es que Django hace muy sencillo mezclar ambos tipos de información dentro de una plantilla.

Variables en lugar de funciones

Quizá el ejemplo más claro sea el título del artículo.

En WordPress era necesario llamar a una función para obtener el título y escribirlo dentro de la etiqueta correspondiente.

// En WordPress
<meta property="og:title" content="<?php echo the_title_attribute( 'echo=0' ); ?>" />

En Django el mismo resultado se obtiene simplemente mostrando la variable correspondiente.

{# En Django #}
<meta property="og:title" content="{{ entry.title }}">

No parece una diferencia muy grande, pero conforme una plantilla comienza a crecer se agradece trabajar directamente con los objetos enviados por la vista, sin necesidad de llamar continuamente a funciones auxiliares.

La imagen del objeto

En este ejemplo todos los artículos comparten la misma imagen Open Graph.

Para ello utilizamos la etiqueta static, que genera automáticamente la ruta correcta hacia los archivos estáticos del proyecto.

<meta property="og:image" content="http://namespace.mx{% static 'img/namespace.logo.png' %}">

Más adelante veremos una versión más completa en la que cada artículo utiliza su propia imagen.

El bloque completo

Todas las propiedades Open Graph pueden colocarse directamente dentro de la plantilla que genera el encabezado del documento.

En mi caso definí un bloque específico para este propósito.

{% block metafacebook %}
    <meta property="og:site_name" content="namespace.mx - Programamos en Python, Django y WordPress">
    <meta property="og:locale" content="es_LA">
    <meta property="og:type" content="article">

    <meta property="og:title" content="{{ entry.title }}">
    <meta property="og:description" content="{{ entry.resumen|truncatewords_html:30|striptags|safe }}">
    <meta property="og:url" content="http://namespace.mx{{ entry.permalink }}">

    <meta property="og:image" content="http://namespace.mx{% static 'img/namespace.logo.png' %}">
    <meta property="og:image:type" content="image/jpeg">
    <meta property="og:image:width" content="200">
    <meta property="og:image:height" content="200">
{% endblock metafacebook %}

Como puede verse, prácticamente todo el trabajo consiste en escribir las etiquetas HTML y sustituir los valores variables mediante el sistema de plantillas.

No es necesario registrar hooks, escribir funciones auxiliares ni recorrer estructuras adicionales.

Una pequeña ventaja de Django

Una de las cosas que más me gusta de este enfoque es que la presentación permanece donde debe estar: en la plantilla.

La vista únicamente se encarga de obtener el objeto Entry y enviarlo al contexto. Después, la plantilla decide qué propiedades Open Graph deben generarse y cómo se mostrarán.

Eso hace que el código sea bastante fácil de leer. Si en algún momento necesito agregar una nueva propiedad o modificar una existente, basta con editar la plantilla correspondiente.

Ésta es una de las razones por las que disfruto trabajar con Django. Gran parte del código termina pareciéndose al HTML que finalmente recibe el navegador, y eso hace que muchas tareas resulten considerablemente más sencillas que en otros frameworks.