3 Grandes cosas que le sucederán a WordPress en el futuro próximo

Nota de la redacción

Este es un artículo creado por nuestro nuevo compañero “campina”. Gracias a su trabajo, hoy podemos traeros la traducción del artículo original en inglés: 3 Big Things that Will Happen to WordPress in the Near Future aparecido la semana pasada en WPTavern. Un artículo que me llamó mucho la atención y que le pedí que fuera el primero en traducir. Leerlo, es realmente interesante ver predicciones de alguien que conoce el futuro de WordPress y la tecnología. Aprovecho otra vez más para darte las gracias campina, espero leer muchos más artículos traducidor por ti en estas líneas.

Publicado por Sarah Gooding el 12 de mayo de 2015

Este artículo de opinión fue aportado por el autor invitado Peter Suhm. Peter es un desarrollador web de la Tierra del Gran Danés. Él es el creador de WP Pusher y un enorme adicto a los viajes, con lo que lleva su trabajo junto a él a medida que viaja.

_____________________________________________________________________________

Sin embargo, otra profecía WordPress

De acuerdo, admito que el título de este post es un poco arriesgado. Honestamente, probablemente debería haber sido “3 Grandes cosas que espero de todo corazón vayan a pasar en WordPress en un futuro no muy lejano”. Dicho esto, soy optimista por naturaleza, y de hecho creo que estas tres ideas son escenarios realistas. Así que con toda modestia, y sin más preámbulos, aquí está mi opinión sobre algunas de las próximas grandes cosas que han de suceder en el mundo de WordPress en un futuro próximo.

WordPress tendrá Gestión de Dependencias

No hay duda al respecto. WordPress necesita algún tipo de mecanismo de gestión de la dependencia. Hemos visto todos los otros fragmentos de la comunidad PHP y otros idiomas también, adoptar el uso de gestores de dependencia. Lo más probable, WordPress adoptará Composer de alguna forma, o bien fuera de la caja, o mediante configuración.

¿Qué es un gestor de dependencias?

Un gestor de dependencia es una herramienta de software que puede resolver y gestionar las dependencias (otras bibliotecas) que una biblioteca dada requiera. En PHP tenemos Compositor. Cada biblioteca PHP que soporta Compositor tendrá un conjunto definido de dependencias de las que él depende. El papel de Composer es traer todas estas dependencias y asegurarse de que son todas compatibles entre sí.

… y ¿por qué necesita uno WordPress?

WordPress necesita uno, así que no tenemos que reinventar la rueda cada vez que queremos crear un nuevo plugin o tema. Cada vez que escribimos código para WordPress, cuando podríamos haber utilizado uno de los paquetes de PHP existentes por ahí, estamos esencialmente desperdiciando nuestro tiempo. Permitir el uso de las dependencias de terceros hace al desarrollo mucho más rápido y mejora la seguridad. Así que muchos problemas de seguridad en los plugins de WordPress son los mismos que se muestran una y otra vez.

¿Qué significa esto para usted?

En el corto plazo, para los desarrolladores de plugins, la adopción de WordPress de un gestor de dependencia supondrá una gran oportunidad para crear plugins WordPress específicos para todas las bibliotecas de PHP existentes por ahí. Cuando esto suceda, vamos a ver cientos, si no miles, de plugins que no sólo serán envoltorios WordPress alrededor de las bibliotecas existentes. Algunos de estos plugins terminarán siendo muy populares.¡ Así que esté listo si usted es un próximo autor de plugins!

Desarrolladores de WordPress probablemente tendrán también que lidiar con algún tipo de gestor de la dependencia interfaz, ya que, con la WP REST API, se revolucionó un montón de cosas en el lado de la interfaz de las cosas. Tocaremos más sobre esto en la siguiente sección.

WordPress será “sólo” un motor

Esta no es mi idea, pero estoy seguro de que este es el camino en que nos estamos moviendo. Con la API REST WP en el núcleo, WordPress será esencialmente un motor, con la gestión de usuarios y así sucesivamente, para su aplicación web basada en la API. Los temas estarán basados en ​​JavaScript y se comunicarán con WordPress a través de la API. Los plugins permanecerán principalmente en PHP, con una pizca de JavaScript, así como la interfaz lo hará. Creo que la razón principal para el éxito generalizado de WordPress es el tablero de instrumentos. Es extremadamente fácil de usar e intuitivo. A esto se añade lo simple y fácil que es añadir plugins de terceros y temas, y usted tiene un ganador. Extender núcleo también es realmente trivial a causa de todas las acciones y filtros que WordPress ha construido. No hay manera de que la API REST WP vaya a cambiar esto. Simplemente es la adición de una capa extra para los desarrolladores de interfaz, y muy probablemente, cambiará radicalmente la forma en que trabajamos con la tematización.

Pocos años atrás trabajé en tiempo completo como desarrollador de Ruby on Rails. Para un proyecto, necesitábamos algún tipo de CMS para gestionar el contenido de nuestra aplicación Rails. Uno de los desarrolladores (un tipo de Ruby endurecido) sugirió usar el panel de WordPress como motor y simplemente construir una API simple alrededor. Nunca terminamos de hacer eso, pero imaginamos lo fácil que sería para implementarlo, de haber existido la API en ese momento.

¿Qué significa esto para usted?

Si usted es desarrollador de temas de WordPress, esto significa que en el futuro es probable que no sea más un desarrollador de WordPress. Va a ser “sólo” un desarrollador de temas. Será mejor afirmar aquellas habilidades JavaScript antes de que esto suceda.

WordPress se volverá más disociado

Como resultado de todo esto, WordPress se convertirá en mucho más desacoplado. Obviamente, el mayor recorte será de entre el motor (tablero de instrumentos y plugins) y el interfaz (temas). También es fácil de imaginar, con una adaptación del Compositor, ese núcleo en sí se convertirá en mucho más disociado. Tal vez similar a cómo se divide el marco Laravel en los paquetes de Illuminate (aunque ahora tendremos que definir lo que significa “futuro cercano”).

Como ya se mencionó, el componente principal será el tablero. Tiene sentido mantener los plugins como parte del tablero, pero en el futuro, puede ser que los vean como paquetes WordPress específicos de Compositor. Tiene sentido mantener todo esto en PHP – por supuesto con un poco de JavaScript aquí y allá. Otra cosa a tener en cuenta es que si Compositor se adopta en un futuro próximo, naturalmente, significaría una actualización de la mínima versión de PHP requerida. Eso probablemente ocurrirá muy pronto, de todos modos. Podríamos ver algún tipo de plugin en la interfaz también, pero estos serán JavaScript y serán gestionados a través de una herramienta de dependencia de interfaz.

¿Qué significa esto para usted?

Esto significa que si usted es un desarrollador de plugins de WordPress, puede seguir escribiendo buen viejo código PHP. No hay necesidad de saltar directamente a NodeJS, todavía, pero si usted es un desarrollador de temas, es posible que deseara mantener un ojo en lo que los chicos están haciendo. También significa que WordPress va a ser mucho más disociado y personalizable. Usted será capaz de recoger las piezas que necesita y omitir el resto. Si necesita algo diferente, lo más probable es que sea capaz de encontrar un paquete PHP existente que pueda hacer el trabajo. Suena bien, ¿verdad?

Estos son mis 5 centavos. Tengo curiosidad por saber lo que piensa usted. ¿Hacia dónde va WordPress?

Quién es Sarah Gooding

Sarah Gooding es un Editorialista Ninja en Audrey Capital. Cuando no está escribiendo sobre WordPress, disfruta en hornear, hacer punto, juzgar competiciones de cerveza y pasar tiempo con su galgo italiano.