- WordPress cumple 21 años desde que Matt Mullenweg y Mike Little hicieron un fork de b2/cafélog y lanzaron la primera versión, y en el desarrollo futuro debe volver a aferrarse a las condiciones que hicieron posible su éxito inicial
- La dirección del producto está alineada con el principio de hacer que lo fácil sea intuitivo, sin dejar de permitir tareas complejas
- Las funciones web dinámicas como blogging, comentarios y pingback hacen que los sitios web sean más interesantes, y se valora más a los sitios dinámicos que a los estáticos
- El ecosistema de plugins y temas debe contar con infraestructura de desarrollo al nivel del core de WordPress; en 2024, depender de la subida de ZIP no tiene sentido
- Los ciclos de retroalimentación cercanos a los usuarios, los foros centrados en la comunidad, buenas vistas previas de temas y Playground definirán la experiencia futura de WordPress
El 21.º aniversario de WordPress y sus principios de producto
- WordPress cumple 21 años desde que Matt Mullenweg y Mike Little hicieron un fork del trabajo de Michel en b2/cafélog y lanzaron la primera versión
- En el desarrollo futuro también hay que seguir teniendo presentes los factores que contribuyeron al éxito inicial de WordPress
- El principio central del producto es que lo simple debe ser fácil e intuitivo, y que lo complejo también debe ser posible
Blogs, documentación y funciones de comunidad
- Los blogs, los comentarios y los pingbacks deben ser divertidos
- Los sitios web estáticos están bien, pero la postura es que los sitios web dinámicos son mejores
- Casi cualquier sitio puede mejorar si tiene un buen blog
- La documentación debe poder editarse tan fácilmente como una wiki
- Las wikis se consideran herramientas “asombrosas”
- En la comunidad, los foros deben ocupar un lugar central
- bbPress y BuddyPress necesitan más atención
Ecosistema de plugins y temas
- Todos los plugins y temas deben contar con infraestructura de desarrollo del mismo nivel que la que se usa para crear WordPress
- Control de versiones
- Rastreador de bugs
- Foros
- Documentación
- Internacionalización
- Salas de chat
- P2
- Un camino sencillo hacia la contribución y la comunidad
- En 2024 no es adecuado tratar plugins y temas mediante subidas de ZIP
- Las vistas previas de temas deben ser excelentes
- Es importante contar con una colección de temas no comerciales con distintas estéticas y funcionalidades
Ciclos de retroalimentación y transparencia por encima de las reglas
- No hay que inclinarse demasiado hacia las directrices y los requisitos
- Es mejor diseñar buenas dinámicas de marketplace, ciclos de retroalimentación automatizados y transparencia hacia los usuarios
- Hay que empujar más los límites de la funcionalidad y el diseño
- Debe haber tolerancia cero frente al spam y los comportamientos similares al spam
- Los ciclos de retroalimentación deben escalar en función del uso y de toda la comunidad, en lugar de depender de gatekeepers
La personalidad del core y los puntos de contacto con el usuario
- El core de WordPress debe tener opinión propia y ser distintivo
- Easter eggs
- Un lenguaje con personalidad, aunque sea difícil de traducir
- Una personalidad como la del jazz
- Todas las personas que desarrollan el software y toman decisiones deben usar ese software
- Los desarrolladores y quienes toman decisiones deben mantenerse cerca de los usuarios finales comunes mediante actividades posibles, como soporte, meetups y eventos
Playground y la experiencia inicial
- Se espera que Playground lo cambie todo
- El 27 de mayo de 2003, el día del primer lanzamiento de WordPress, Matt Mullenweg escribió en el porche de la casa de sus padres una entrada de blog de 953 palabras en la que dejó la frase: “Lancé WordPress y me sentí bien”
- Esa noche configuró WP para su amigo Ramie Speight y dio soporte técnico por teléfono a Mike Tremoulet, a quien había conocido en una reunión local de bloggers
- Sus amigos de la secundaria usaban WordPress en sus propios dominios, y ese ciclo de retroalimentación desempeñó un papel importante en la formación del software
1 comentarios
Opiniones en Hacker News
Es una lástima que WordPress no solo no respete los estándares de desarrollo, sino que parezca querer romperlos activamente.
Después de usar variables globales por todas partes y fomentar código espagueti con los temas clásicos, en los temas nuevos hace que se ponga JSON dentro de comentarios HTML, sin soporte del editor, fácil de romper y simplemente un diseño raro.
En serio, uno se pregunta si ingenieros senior decidieron meter plantillas JSON dentro de comentarios HTML; visto de forma conspirativa, también parece un intento de matar el mercado de freelancers y agencias digitales y empujar a la gente hacia el constructor de sitios WYSIWYG de WP.com.
Es algo como HTML dentro de PHP, JS dentro de HTML y CSS dentro de JS, y depende de una estructura implícita sobre qué archivos se leen y en qué orden para construir la página completa.
Al principio parece cómodo, pero hace que un elemento HTML no se cierre correctamente en el mismo archivo y termine cerrándose en otro, impidiendo su reutilización.
Parece un error de principiante, pero miles de temas dependen de eso, así que ya quedaron atados; contrasta con la forma en que las plantillas Jinja2 renderizan bloques y macros.
WordPress existe para clientes sin presupuesto y clientes de bajo costo que creen que necesitan un sitio web simple, y creo que esa idea misma de un sitio simple ya está muerta.
https://timber.github.io/docs/v2/
Al intentar moverlo a un servidor nuevo con una ruta de instalación apenas distinta, se rompía de inmediato.
Lamentablemente, eso podría afectar negativamente el texto de marketing de “nuestra plataforma impulsa el 43.4% de todos los sitios web”.
Es una lástima que los juicios rápidos y las opiniones fuertes se hayan vuelto parte de la comunidad.
Después de hacer bastante desarrollo con WordPress en los últimos 2 o 3 meses, quiero decir que el aislamiento de código que ofrecen los bloques (Gutenberg) es excelente.
Usándolo como plugin independiente o junto con Advanced Custom Fields, se puede crear un sitio web completamente modular y un flujo de desarrollo —es decir, un sistema de diseño— con control directo del 100% del HTML.
Recomiendo a todos entender y aprender bien WordPress. No tengo ninguna relación ni vínculo con WordPress.
Hoy, de repente, Gutenberg y ACF Blocks están chocando en algún lugar por el parseo del contenido de un campo multimedia anidado.
La causa podría ser “el usuario puso una descripción de imagen que no debía poner”, o “un objeto global del plugin contaminó otro objeto global que se le pasa a
acf_register_block_type()”.Quizá tenga que llamar a un cliente que ya está enojado y decirle que evite los juicios rápidos y las opiniones fuertes.
Puede que hoy ya no sea así, pero es natural ser escéptico. En las actualizaciones que reviso cada semana veo bastantes CVE, aunque quizá todas sean de bajo riesgo o estén relacionadas con plugins que casi nadie usa.
index.phpde WordPress para intentar entender cómo funcionaba.Recuerdo que no pude entender nada salvo el comentario al principio del archivo que decía “code is poetry”.
Gracias a eso cambió mi forma de pensar sobre el código y me metí aún más en la programación.
Si una entrada necesita metadatos, instalas ACF; si intentas filtrar por esos metadatos, en cuanto aplicas unos pocos filtros al mismo tiempo la consulta SQL hace timeout. Al ver el esquema raro de WP se entiende por qué.
Gutenberg promete componentes React editables con WYSIWYG, pero toma decisiones extrañas: guarda los atributos dentro del HTML, mete el HTML renderizado en la base de datos y obliga al desarrollador del componente a mantener un array de cambios deprecated cada vez que modifica algo.
También hay intentos de refactorizar WordPress y acoplarle Laravel para desenredarlo[1], pero cada capa es una pesadilla, y parece difícil que incluso los autores de las distintas partes puedan determinar bien por qué algo se rompe de forma aleatoria.
El ecosistema de plugins puede ser atractivo, pero las implementaciones de los plugins son muy dispares, así que es muy probable que termines empujando al usuario montones inflados de CSS y JS.
Yo me pasé a Directus y Astro, y para un despliegue PHP más general creo que usaría un CMS basado en Laravel como October o Statamic.
[1]: https://roots.io/
Entre 2009 y 2011 trabajé bastante con él, incluso escribiendo y modificando plugins, pero nunca sentí que lo entendiera bien; más bien lo entendía o lo aceptaba a grandes rasgos.
Me gusta WordPress. La gente lo instala por su cuenta, mete decenas de plugins inútiles, inseguros y llenos de bugs, y cuando con el tiempo el sitio se rompe, puedes cobrarles por una solución más segura y sólida.
Daba la impresión de ser un proyecto de fin de semana inconcluso que se alargó demasiado y luego se publicó; procesaba cosas con un loop
forde cinco pantallas, duplicado, dando vueltas sobre una enorme variable global.WordPress es mi ejemplo favorito de “no tiene que ser perfecto, solo tiene que funcionar”.
Muchos proyectos excelentes mueren porque complican demasiado el primer paso. Una vez que la gente empieza a usarlo, siempre puedes mejorarlo después, pero primero hay que lanzarlo.
Es tan grave que incluso los desarrolladores del lenguaje PHP no pueden implementar algunas funcionalidades o correcciones, porque el equipo de WordPress no quiere migrar el código y WordPress representa una gran parte del uso de PHP.
WP es la herramienta perfecta para el 95% del trabajo, pero ajustar el 5% final es tremendamente frustrante.
Lo he usado mucho, y creo que el hecho de que haya sobrevivido tanto tiempo es prueba de su utilidad. Espero que siga otros 21 años más.
Sinceramente, nunca sentí que WordPress fuera fácil de usar. Todo se ve color de rosa solo hasta que puedes encontrar un buen tema y buenos plugins; en cuanto necesitas el más mínimo cambio personalizado, empiezan los enredos.
Pero al abrir el sitio, el código de plugins/temas y los archivos CSS, terminaba peleándome durante horas para lograr el efecto deseado, y aunque lo consiguiera, solía romper otra parte del sitio.
Dejando de lado la anécdota despectiva, bien hecho Matt, y la historia final también estuvo buena.
Las actualizaciones requieren intervención manual, los temas hay que repararlos y los plugins quedan abandonados. Como no quería asumir esa carga, desde alrededor de 2017 moví todos mis sitios a Hugo/Jekyll/MkDocs, etc.
Para un blog preferiría usar Ghost antes que WP, y también prefiero JS sobre PHP.
Es interesante que, aunque varias personas digan “soy desarrollador de WordPress”, en realidad se refieren a experiencias y conjuntos de habilidades completamente distintos.
Para algunos significa instalar temas y plugins desde el panel de administración de WordPress y redactar el contenido de las páginas.
Para otros significa código PHP a la antigua, es decir, temas clásicos, donde se escribe HTML con plantillas PHP y se personaliza el comportamiento de WordPress.
Para otros significa los nuevos temas de bloques, escribiendo JS+React junto con Docker y CI/CD.
Ojalá más empresas adoptaran la política de sabático de Automattic.
https://automattic.com/benefits/sabbatical/
Lo que te hace sentir viejo es ver “WP” y pensar en WordPerfect(https://en.wikipedia.org/wiki/WordPerfect) en lugar de WordPress.
WordPress ya tiene edad para ser considerado adulto incluso en los países más conservadores, y WordPerfect ya está entrando en la edad de la crisis de la mediana edad.
Lo llamativo de WordPress es que los nerds de la web dan por sentado que debería ser fácil, y se enojan cuando no lo es.
Como todo lo demás, WordPress también hay que aprenderlo, y tiene su propia perspectiva.
Tiene una historia rara, y en particular detesto cómo maneja los elementos multimedia, pero aun así hay una metodología.
Si dijera que sé Go, JS, Perl, Java, Ruby y C, y luego me enojara porque Rust es difícil de aprender, obviamente me lo cuestionarían.
WordPress parece hacer cosas simples, pero en realidad es una plataforma bastante amplia. Quizá tengas que leer un poco de documentación.
Si heredaste un sitio que usa Elementor, puedes preguntarle a quien lo hizo cómo hacer cambios simples y probablemente te pueda ayudar.
Si heredaste un sitio que usa Visual Composer o Divi, te dan ganas de dispararles a quienes lo hicieron.
Si piensas que Gutenberg es malo, hoy ya no lo es para nada. Recordando la época de Divi, aquello sí era terrible.
Si la horrible ejecución de una UI JavaScript montada encima de WordPress sufre el menor timeout, con solo guardar una entrada de blog puede dejar todo el sitio en un estado irrecuperable.
Las localizaciones al italiano y al francés son pésimas, al nivel de los juegos japoneses de los 90, y las opciones responsive básicamente no funcionan, a menos que a ocultar y mostrar contenido en ciertos breakpoints le quieras llamar responsive.
Todo es extremadamente frágil porque el “tema” del frontend se parece más a un volcado ilegible de JavaScript de la era de jQuery.
Estoy 100% seguro de que, si Elegant Themes no gastara una fortuna en publicidad, nadie lo usaría.