El proyecto API de WordPress Core Fields está buscando un nuevo liderazgo

En 2014, el desarrollador principal de Pods, Scott Kingsley Clark, asumió el papel principal principal del proyecto de interfaz de usuario de metadatos. En 2015, el proyecto de interfaz de usuario de metadatos renació como la API de campos.

La API de campos fue desarrollada para permitir registrar campos a diferentes pantallas en el área de administración a través de una sola API. Se pueden agregar nuevos metacuadros y campos dentro de ellos a las publicaciones, mientras que se pueden agregar nuevas secciones y campos a la pantalla de perfil.

El objetivo de la API es integrarse con todas las diversas pantallas de administración, incluidas publicaciones, términos, usuarios, medios y comentarios, y proporcionar estandarización.

Clark ha estado al frente del proyecto durante tres años y, a pesar de ver un interés renovado el año pasado, anunció en el canal de Slack del proyecto que dejará el cargo.

Es con gran pesar que debo pasar la antorcha en este proyecto. Después de cientos de horas de mi tiempo, ya no creo que pueda efectuar cambios dentro del núcleo de WordPress.

La visión de Fields API era demasiado grande, una tarea demasiado grande para una sola persona. Creo profundamente que WordPress necesita una API de campos, pero el viaje hasta donde estamos con la API de campos ha sido largo y arduo.

La verdad es que me quemé hace años mientras construía el primer y segundo prototipo. No todos estuvieron de acuerdo en cómo diseñar el código, pasó por muchas revisiones basadas en los comentarios de los colaboradores principales. Simplemente no pude lograr que suficientes personas se emocionaran al respecto, no pude lograr suficientes empresas y personas interesadas en apoyarlo.

Necesito dejar que alguien más tenga su oportunidad, lo estoy arrastrando hacia abajo. Si alguien da un paso adelante para liderar en el futuro, estaré encantado de ayudar en lo que pueda. Pero no puedo seguir liderando la propuesta/proyecto de API de campos. Lo siento, por favor acepte mis disculpas y espero que pueda perdonarme por no haber llevado este proyecto a la línea de meta. Todavía creo que es una parte tan vital del éxito futuro de WordPress.

scott kingsley clark

Las pruebas y tribulaciones de liderar un proyecto de código abierto

En la siguiente entrevista, Clark explica por qué se siente personalmente responsable de la falta de progreso del proyecto, por qué la API es importante para el futuro de WordPress y reflexiona sobre lo que podría haber hecho de otra manera.

¿Estás buscando pasar la antorcha a alguien en particular?

No, no estoy seguro de quién tendría el impulso y la influencia para llevar a cabo el proyecto. Es un proyecto a gran escala que debe abordarse con una visión a largo plazo pero en incrementos lo suficientemente pequeños como para convertirlo en el núcleo de WordPress. Es mucho pedirle a alguien, tampoco es una prioridad para las personas en este momento, ya que están distraídos por el lanzamiento de Gutenberg en un futuro cercano.

¿Por qué Fields API es una parte vital del futuro de WordPress?

La gente mira WordPress hoy y se pregunta cómo sobrevivieron sin la API REST. Bueno, ¡al menos sé que lo hago! Lo mismo se puede decir sobre la API de campos, aunque todavía no está allí. Hay tantos casos en los que es frustrante crear soluciones para WordPress en todos los ganchos diferentes.

Por consistencia, es el salvaje oeste por ahí. Obtienes un meta box registrado y lo llenas con lo que quieras. Necesita su propio CSS para diseñar los campos del formulario y todos tienen su propia idea de cómo debería verse esta interfaz. Usted está a cargo de sus propios diseños receptivos que son compatibles con dispositivos móviles, hay mucho que tiene que manejar por su cuenta. Debería poder personalizar las apariencias, pero cada lugar al que desee agregar un campo o formulario realmente debería tener una API adecuada.

A largo plazo, imagine registrar campos en WordPress como si registrara tipos de publicaciones. Imagine que los campos y sus configuraciones estén disponibles para la API REST y accesibles a través de la aplicación de WordPress u otras aplicaciones personalizadas.

Todo el mundo se abre porque tiene una API consistente, todo el mundo tiene sentido porque tiene una interfaz consistente para esos campos en las distintas pantallas de edición. Las publicaciones, los términos, los comentarios, los usuarios, los medios e incluso el Personalizador tendrían la misma API subyacente para agregar grupos, paneles y campos a sus pantallas.

Si Gutenberg se hubiera realizado después de que se introdujera la API de Fields, la migración para la gente no habría sido tan difícil. Gutenberg podría haber mostrado automáticamente todas las interfaces de la API de Fields como lo hace para la compatibilidad con versiones anteriores del cuadro meta. Se habría visto mucho mejor también.

Tomando un tiempo para reflexionar, ¿qué podría haber hecho de manera diferente para lograr que más contribuyentes principales participen en el proyecto y lo conviertan en una prioridad más alta?

No estoy seguro, es un delicado equilibrio entre recibir información y tener confianza en el resultado final. Al principio, los comentarios eran sobre cómo la API era ajena a WordPress, preguntaron si podría tener una estructura similar a otras API, como el Personalizador.

Eliminamos el código y lo reconstruimos desde cero como una bifurcación del Personalizador, incluso admitía que el Personalizador también utilizara la API de Campos. En el apogeo del desarrollo, implementamos todas las áreas de la API Fields.

Los lanzamientos principales se movían bastante rápido, hubo muchos cambios en el código de un lanzamiento de WordPress a otro que teníamos que seguir porque esencialmente habíamos creado un proyecto que era un parche gigante para WordPress.

No había suficientes ganchos para hacer lo que necesitábamos hacer, y muchas secciones no eran extensibles debido a decisiones de código que se marcaban a sí mismas como "finales", lo que significa que no puede extender una clase específica para personalizar su funcionamiento.

Ojalá hubiera podido estar en todos los grandes WordCamps en los EE. UU. y Europa, esencialmente cabildeando por esta función. Reunir simpatizantes y demás, se siente como política en cierto modo. Me quedé en las reuniones de desarrollo de Core, tratando de mencionarlo. Traté de legitimar la función teniendo un canal dedicado en el Slack oficial de WordPress, publicando actualizaciones en https://make.wordpress.org/core/ y organizando reuniones semanales.

En última instancia, prioricé mi tiempo de desarrollo sobre el tiempo de reunir las tropas. Esa fue la caída, comencé a agotarme rápidamente después de las primeras reescrituras, ya que tenía muchas otras responsabilidades en otros lugares además de la API de Fields.

No es como si las empresas quisieran fácilmente pagarle por trabajar en un proyecto como este indefinidamente, aunque tanto WebDevStudios como 10up me dieron tiempo para impulsarlo. No fue un cheque en blanco, en algún momento tuve que volver al trabajo facturable. A partir de ese momento, todo fue en mi tiempo libre y eso fue difícil de manejar en tiempos de estrés financiero y compra/venta de casas.

Hay demanda de una API de campos en el núcleo, pero no hay suficientes manos para construirla. ¿Por qué crees que es?

Todos están enfocados en otra parte. Hay muchas áreas de WordPress que necesitan la atención de la gente. Hay cosas como la Accesibilidad que merecen mucha más atención de la que reciben. Pero el enfoque para mí parece estar en Gutenberg y REST API.

Gutenberg especialmente ha sido un gran sumidero de tiempo para las personas que contribuyen y las personas que implementan. Es una característica realmente grande. Definitivamente es más grande en escala que la API de Fields, es como una aplicación completamente nueva que vive en WordPress. La integración con él ha requerido mucha educación y ensayo/error. El enfoque de la gente está donde debe estar en este momento. Es desafortunado que Gutenberg haya llegado antes que Fields API en términos de prioridad y nivel de interés.

¿Qué consejo le daría al próximo líder de proyecto de Fields API?

Este es un gran proyecto, todos querrán decir que debería ser de cierta manera. Tienes que evaluar las opciones y proponer algo del tamaño de un bocado para empezar. Construya sobre eso, pero nunca pierda de vista el objetivo a largo plazo de integración en todas las pantallas de WordPress. Incluso los formularios de comentarios de front-end podrían prosperar con la API de campos.

¿Por qué se siente personalmente responsable de que el proyecto no sea una prioridad central?

En un momento, tuvimos impulso. Teníamos al menos tres o cuatro personas activas. Se vino abajo porque se me acabó el tiempo. Es mi miopía, es mi culpa. Pasé cientos de horas desarrollando el proyecto durante un par de años. Debería haberme dejado mucho más tiempo para organizar el texto de la propuesta de funciones y mantener el fuego encendido en los corazones de nuestros colaboradores.

Teniendo en cuenta el tiempo y el esfuerzo que ha dedicado al proyecto en los últimos años, ¿siente alguna sensación de alivio al pasar la antorcha?

Si me pasan o recogen la antorcha, me sentiré muchísimo mejor. El principal alivio es que oficialmente ya no es un peso que tengo que cargar solo. Está bien intentarlo y fallar, aunque sigue siendo triste.

Espero que alguien o alguna compañía dé un paso adelante y dedique tiempo a esto. Incluso podrían volver a encender el fuego en mi propio corazón que se apagó solo. Por ahora, tengo una tarea importante menos pendiente. Todavía tengo un plato pesado, pero ya no es una carga tan pesada.

Si bien el futuro inmediato del proyecto no está claro, se recomienda a los interesados ​​en hacerse cargo de él que lean las publicaciones marcadas con la etiqueta Fields API en Make.WordPress.Core para conocer su historia. También puede consultar la página de Github del proyecto.

Si está interesado en hacerse cargo del proyecto, puede comunicarse con Clark en Twitter, Slack o a través de su sitio web.