Novedades en el calendario editorial de Nelio Content

La semana pasada, Antonio explicaba qué hacer cuando un cliente cancela su suscripción a tus plugins y recomendaba contactar con él para entender los motivos de dicha cancelación (y, con suerte, intentar evitar que se vaya). Una de las principales ventajas de hablar con ex-clientas es que pueden decirte qué cosas puedes mejorar de tu plugin. A fin de cuentas, han sido usuarias durante un cierto tiempo de tus plugins y conocen bien cuáles son sus puntos fuertes y cuáles son sus puntos débiles.

En Nelio siempre decimos que nos gusta escuchar a nuestras usuarias y ex-usuarios para entender sus necesidades y poder así adaptar mejor nuestra oferta. En la entrada de hoy, veremos qué novedades trae Nelio Content y cómo su implementación ha sido fruto directo del feedback que hemos recibido.

Feedback

Para conseguir que tu plugin tenga éxito debes escuchar a tus usuarios y darles lo que necesitan. A fin de cuentas, se supone que has creado el plugin para solucionar un problema concreto que ellos sufren y conocen a la perfección. Por lo tanto, nadie mejor que tus usuarias para saber cómo mejorar tu solución.

En este sentido, en Nelio disponemos de varios canales a través de los cuales podemos hablar con nuestras usuarias: el correo electrónico, las redes sociales, el sistema de tickets de soporte en Freshdesk, los hilos de soporte en WordPress.org y los comentarios en nuestro blog. Ruth, Toni y yo estamos monitorizando continuamente todos estos canales y procuramos atender a todas las peticiones, comentarios e ideas que nos llegan.

Una petición que venía repitiéndose últimamente estaba relacionada con el editor de entradas del calendario editorial de Nelio Content. Hasta ahora, cuando creabas o editabas una entrada desde el calendario editorial, nuestro plugin te mostraba el siguiente diálogo modal:

Con él, podías especificar el tipo de contenido (entrada, página, etc) junto a su título, autor y fecha y hora de publicación. Además, si estabas creando una entrada, podías especificar la categoría principal en la que querías que apareciera.

Hace un par de semanas nos escribía un usuario por WordPress.org con la siguiente petición:

Hola. Veo que cuando creamos una nueva entrada en el calendario, el formulario sólo nos permite seleccionar una categoría raíz y no una subcategoría. Sin embargo, cuando publicamos nuevos contenidos, nuestros editores deben seleccionar una subcategoría y no preocuparse por la categoría principal. Para nosotros, sería mejor que únicamente se pudieran escoger subcategorías. O subcategorías y categorías principales, claro. ¿Es posible?

w-sky en WordPress.org

En otras palabras, dada una jerarquía de categorías como esta:

• WordPress
  • Plugins
    • Plugins Premium
    • Plugins Gratuitos
  • Temas
  • Comunidad
• Negocio
  • Servicios
  • Ideas
• Marketing

La versión anterior de Nelio Content únicamente permitía seleccionar WordPress, Negocio y Marketing, aunque su equipo necesitaba poder seleccionar cualquier categoría (WordPress, Plugins, Plugins Gratuitos, Servicios, etc).

Pero es que aún hay más. Unos días antes de recibir esa petición, entró un email de otra usuaria pidiendo exactamente lo mismo y, además, la posibilidad de poder modificar no solo las categorías, sino también las etiquetas. Y un par de semanas antes, otro usuario pedía poder modificar el estado de la entrada y modificar su apariencia en el calendario (ya que, por si no lo sabías, las entradas del calendario usan diferentes colores e iconos según el estado en que están):

Es decir, está claro que la gente esperaba más de nuestro calendario editorial y no se lo estábamos dando. Nosotros en su día supusimos que el editor de entradas debía ser algo sencillito… y ahora tenemos a nuestras usuarias pidiéndonos más opciones de personalización y edición. No se hable más, pues: ¡a trabajar!

Implementación del nuevo editor de entradas

Lo primero que hicimos fue modificar el editor de entradas del calendario editorial de Nelio Content. Para ello, optamos por desechar el código original (que usaba High-Order Components) y escribirlo de nuevo usando React hooks. De esta forma, poco a poco vamos modernizando y actualizando el código fuente de Nelio Content.

Para que te hagas una idea del resultado, permíteme que te enseñe un ejemplo. El componente original con el que poner la hora de publicación de una entrada era algo tal que así:

/**
 * Internal dependencies
 */
import { compose } from '@wordpress/compose';
import { withSelect, withDispatch } from '@wordpress/data';
/**
 * Internal dependencies
 */
import { TimeInput } from '@nelio-content/components';
const TimeSelector = ( {
  canUserEditPost,
  disabled,
  isPublished,
  setTimeValue,
  timeValue,
} ) => (
  <div className="nelio-content-post-quick-editor__time">
    <TimeInput
      disabled={ disabled || isPublished || ! canUserEditPost }
      type="time"
      value={ timeValue }
      onChange={ setTimeValue }
    />
  </div>
);
const withTime = withSelect( ( select ) => {
  const { getTimeValue, isPublished } = select(
    'nelio-content/post-quick-editor'
  );
  return {
    timeValue: getTimeValue(),
    isPublished: isPublished(),
  };
} );
const withTimeSetter = withDispatch( ( dispatch ) => {
  const { setTimeValue } = dispatch( 'nelio-content/post-quick-editor' );
  return { setTimeValue };
} );
export default compose( withTime, withTimeSetter )( TimeSelector );

Sin duda, un componente que, a pesar de ser sencillo, resultaba un poco caótico. Algunas de las props que le entran (timeValue, isPublished y setTimeValue) vienen dadas por los HOC que ves en el fragmento de código anterior con withSelect y withDispatch, mientras que otras (disabled o canUserEditPost) las pone el componente padre.

La nueva versión de este componente es mucho más elegante:

/**
 * WordPress dependencies
 */
import { useSelect, useDispatch } from '@wordpress/data';
/**
 * External dependencies
 */
import { TimeInput } from '@nelio-content/components';
/**
 * Internal dependencies
 */
import { useIsDisabled, useIsPublished } from '../hooks';
export const TimeSelector = () => {
  const [ time, setTime ] = useTime();
  const disabled = useIsDisabled();
  const published = useIsPublished();
  return (
    <div className="nelio-content-post-quick-editor__time">
      <TimeInput
        disabled={ disabled || published }
        type="time"
        value={ time }
        onChange={ setTime }
      />
    </div>
  );
};
// =====
// HOOKS
// =====
const useTime = () => {
  const timeValue = useSelect( ( select ) =>
    select( 'nelio-content/post-quick-editor' ).getTimeValue()
  );
  const { setTimeValue } = useDispatch( 'nelio-content/post-quick-editor' );
  return [ timeValue, setTimeValue ];
};

ya que ahora no recibe ninguna prop y los valores que necesita para funcionar los obtiene mediante hooks, resultando en un código mucho más sencillo y fácil de entender.

Como punto interesante, creo que merece la pena comentar la implementación del hook useTime, puesto que igual puede servirte en tus proyectos. Este hook usa los hooks de WordPress useSelect y useDispatch, los cuales nos permiten, por un lado, leer un valor de nuestro store y, por otro, acceder a una función del mismo con la que actualizarlo. En este caso, lógicamente leemos la «hora de publicación» que tenemos en el store y recuperamos la función con la que modificarla. El resultado de useTime es una tupla (implementada como un array) con ambos elementos, imitando así el comportamiento por defecto del hook useState y, por lo tanto, ofreciendo una experiencia de usuaria/programadora familiar.

El resultado del nuevo editor lo puedes ver en la siguiente captura de pantalla:

Huelga decir que si quieres cotillear un poco más el código fuente de este nuevo editor, lo tienes todo disponible aquí.

Nelio Content

Estoy tan contento con Nelio Content que parece que me hayan pagado para hablar bién de él… pero es que también a ti te encantará: funciona como prometen, la programación automática de mensajes es increíble, la calidad/precio no tiene parangón y su equipo de soporte se siente como si fueran parte del tuyo.

Panozk

WordPress.org

Ver planes

Editando una entrada existente…

El editor de entradas de nuestro calendario editorial siempre ha permitido (a) crear nuevas entradas y (b) editar entradas existentes. Aunque el editor es, en esencia, el mismo en ambos casos, cuando editas una entrada existente ofrece algunas opciones adicionales para acceder a más información sobre la misma.

En la siguiente captura de pantalla puedes ver las opciones adicionales disponibles cuando editamos una entrada existente.

Como ves, hemos optado por agrupar dichas opciones en un componente tabulado:

• Taxonomías. Sólo está disponible cuando editas una entrada y permite modificar las categorías y etiquetas de la misma.
• Tareas. Permite consultar todas las tareas que hay asociadas a la entrada. Actualmente, se trata de una opción de «solo lectura», pero no descartamos que en un futuro se puedan crear, eliminar y modificar las tareas existentes.
• Referencias. Permite consultar las referencias sugeridas de una entrada. De nuevo, se trata de una opción de «solo lectura».

Nuevo filtro para personalizar los estados

Comparando las capturas de pantalla de la versión anterior y actual del editor de entradas, verás que en la nueva es posible cambiar el estado de las mismas: Borrador, Pendiente, Programada, etc. Estos estados también se reflejan en el propio calendario editorial, donde cada entrada tiene un color según el estado en el que se encuentra.

¿De dónde salen estos estados? ¿Hay alguna forma de personalizar qué estados hay disponibles para cada tipo de contenido? ¿Podemos modificar la apariencia de los mismos en el calendario?

Hasta ahora, la respuesta a estas preguntas era simple: los estados estaban definidos explícitamente en el código de Nelio Content y no se podía modificar nada. Pero esto es algo que ha cambiado con la última actualización de Nelio Content.

El problema con get_post_stati

En WordPress, existe una función para registrar nuevos estados: register_post_status. Y también existe una función (get_post_stati) con la que recuperar todos los estados que hay disponibles en WordPress (tanto los que vienen por defecto con WordPress como los que han registrado tus plugins con la función anterior). Teniendo en cuenta esto, parece razonable usar get_post_stati para recuperar todos los estados de WordPress y poder usarlos desde Nelio Content, ¿no? No exactamente.

El «problema» de estas funciones es que los (nuevos) estados no están asociados a un tipo de contenido concreto y, por lo tanto, en teoría podrían usarse en cualquiera: páginas, entradas, productos, lo que sea. Por ejemplo, si echas un vistazo al código fuente de WooCommerce, verás que en el fichero includes/class-wc-post-types.php línea 557 define los estados en los que puede estar un pedido de WooCommerce: Pendiente, En proceso, Completado, etc. Ninguno de estos está asociado de forma alguna con el tipo de contenido shop_order, con lo que, en teoría, podría asignar el estado, qué sé yo, wc-pending a una entrada de mi blog. No tiene ningún sentido, pero podría hacerlo. Y es que los estados personalizados son algo que no está del todo bien pensado en WordPress; de hecho, hay un bug del 2010 sobre el tema.

A la práctica, este problema no se da, porque los editores de cada tipo de contenido están capados. Así, el editor de entradas de WordPress únicamente muestra los estados por defecto de WordPress y el editor de pedidos de WooCommerce está programado para mostrar únicamente los estados del propio WooCommerce. Pero, claro, si nuestro plugin recuperara todos los estados disponibles con get_post_stati y los mostrara en el editor de entradas del calendario editorial… ¿cómo puede saber que hay algunos estados que no deben usarse en entradas porque están pensados para pedidos de WooCommerce?

Solución

Al final, hemos optado por la mejor solución posible: darle el poder al usuario. En concreto, hemos creado un nuevo filtro nelio_content_post_statuses con el que, dado un tipo de contenido concreto, es posible definir qué estados hay disponibles.

Por ejemplo, imagina que quieres añadir el estado «En progreso» (in-progress) a una entrada para que el editor de un blog pueda saber que el autor de una entrada está trabajando en ella. Tal y como te acabo de explicar, este estado debería haberse registrado en WordPress usando la función register_post_status. Pero, a pesar de estar registrada, nuestro plugin no sabe que existe y que debe estar disponible para entradas. ¡No hay problema! Usando el filtro podemos solucionarlo:

add_filter(
  'nelio_content_post_statuses',
  function ( $statuses, $post_type ) {
    if ( 'post' !== $post_type ) {
      return $statuses;
    }
    $statuses[] = array(
      'slug'   => 'in-progress',
      'name'   => 'In Progress',
      'icon'   => 'format-status',
      'colors' => array(
        'main'       => '#f9d510',
        'background' => '#fffdf1',
      ),
    );
    return $statuses;
  },
  10,
  2
);

¡Y ya estaría! Cuando el tipo de contenido en cuestión es post, añadimos el nuevo estado usando el formato anterior:

• slug es el nombre interno del estado
• name es la etiqueta que se muestra en la interfaz de usuario
• icon es un atributo opcional cuyo valor es el nombre de un dashicon
• colors es un atributo opcional con el que especificar el color en el calendario de las entradas con ese estado (main es el color del border superior y background el color de fondo)

¡Escucha a tus usuarias!

La mejor forma de evolucionar un producto y asegurar que encaja con el público objetivo es, ¡oh, sorpresa!, escuchando al público objetivo. En Nelio siempre estamos atento a las peticiones de nuestras usuarias y adaptamos nuestros plugins a sus necesidades. Hoy hemos visto cómo los comentarios de varios clientes nos han ayudado a mejorar Nelio Content y nos han permitido añadir nuevas funcionalidades que convierten a Nelio Content en un plugin más completo y útil.

Y tú, ¿cómo lidias con las peticiones de los clientes? ¿Cómo priorizas sus peticiones? Cuéntanoslo en la caja de comentarios.

Imagen destacada de XiaoXiao Sun en Unsplash.