Gutenberg

Descripción

Gutenberg es más que un editor. Aunque el editor es donde está el enfoque ahora mismo, el proyecto impactará definitivamente en toda la experiencia de publicación, incluida la personalización (la próxima área de enfoque).

Descubre más sobre el proyecto.

Enfoque en la edición

El editor creará una nueva experiencia de creación de páginas y entradas que hará que escribir publicaciones enriquecidas no conlleve esfuerzo alguno, y tiene los “bloques” para hacer fácil lo que actualmente requiere shortcodes, HTML personalizado, o descubrir “comida basura” incrustada. — Matt Mullenweg

Una cosa que distingue a WordPress de otros sistemas es que te permite crear una distribución de publicaciones tan completa como te puedas imaginar — pero sólo si sabes HTML y CSS y construye su propio tema personalizado. Al pensar en el editor como una herramienta que te permite escribir publicaciones ricas y crear hermosos diseños, podemos transformar WordPress en algo que los usuarios aman de WordPress, en lugar de algo que eligen porque es lo que todos los demás usan.

Gutenberg considera el editor como algo más que un campo de contenido, y revisita un diseño que ha permanecido prácticamente inalterado durante casi una década. Esto nos permite diseñar holísticamente una experiencia de edición moderna y construir una base para lo que vendrá.

He aquí por qué estamos mirando toda la pantalla de edición, en lugar de solo el campo de contenido:

  1. El bloque unifica múltiples interfaces. Si agregamos eso en la parte superior de la interfaz existente, agregaría complejidad, en lugar de eliminarla.
  2. Al volver a visitar la interfaz, podemos modernizar la experiencia de escritura, edición y publicación, teniendo en cuenta la facilidad de uso y la simplicidad, lo que beneficia tanto a los usuarios nuevos como a los ocasionales.
  3. Cuando la interfaz de bloque singular toma el centro del escenario, muestra un camino claro hacia adelante para que los desarrolladores creen bloques premium, superiores a shortcodes y widgets.
  4. Considering the whole interface lays a solid foundation for the next focus, full site customization.
  5. Mirar la pantalla completa del editor también nos brinda la oportunidad de modernizar drásticamente la base y dar pasos hacia un futuro más fluido y con JavaScript que aproveche al máximo la API REST de WordPress.

Bloques

Los bloques son la evolución unificadora de lo que ahora está cubierto, de diferentes maneras, mediante shortcodes, incrustaciones, widgets, formatos de publicación, tipos de contenido personalizados, opciones de tema, meta-boxes y otros elementos de formato. Adoptan la amplitud de la funcionalidad que WordPress es capaz de ofrecer, con la claridad de una experiencia de usuario consistente.

Imagina un bloque “empleado” personalizado que un cliente puede arrastrar a una página Acerca de para mostrar automáticamente una imagen, nombre y biografía. Todo un universo de plugins que extienden WordPress de la misma manera. Menús y widgets simplificados. Usuarios que pueden entender y usar instantáneamente WordPress — y el 90% de los plugins. Esto te permitirá redactar fácilmente publicaciones hermosas como este ejemplo.

Consulte las FAQ para obtener respuestas a las preguntas más frecuentes sobre el proyecto.

Compatibilidad

Las publicaciones son compatibles con versiones anteriores, y los shortcodes seguirán funcionando. Estamos explorando continuamente cómo se pueden acomodar metaboxes altamente personalizados, y estamos buscando soluciones que van desde un plugin para deshabilitar Gutenberg hasta detectar automáticamente si cargar Gutenberg o no. Si bien queremos asegurarnos de que la nueva experiencia de edición desde la escritura hasta la publicación sea fácil de usar, nos comprometemos a encontrar una buena solución para sitios existentes altamente personalizados.

Las etapas de Gutenberg

Gutenberg tiene tres etapas planificadas. La primera, destinada a la inclusión en WordPress 5.0, se centra en la experiencia de edición posterior y la implementación de bloques. Esta fase inicial se centra en un enfoque de el primero primero. El uso de bloques, como se detalla anteriormente, le permite enfocarse en cómo se verá su contenido sin la distracción de otras opciones de configuración. Esto finalmente ayudará a todos los usuarios a presentar su contenido de una manera atractiva, directa y visual.

Estos elementos fundacionales allanarán el camino para las etapas dos y tres, planificadas para el próximo año, para ir más allá de la publicación en plantillas de página y, en última instancia, la personalización completa del sitio.

Gutenberg es un gran cambio, y habrá formas de garantizar que la funcionalidad existente (como los shortcodes y los meta-boxes) continúe funcionando mientras que da a los desarrolladores el tiempo y los caminos para la transición de manera efectiva. En última instancia, abrirá nuevas oportunidades para que los desarrolladores de plugins y temas brinden un mejor servicio a los usuarios a través de una experiencia más atractiva y visual que aproveche un conjunto de herramientas respaldadas por el core.

Colaboradores

Gutenberg está construido por muchos colaboradores y voluntarios. Consulte la lista completa en CONTRIBUTORS.md .

Preguntas frecuentes

¿Cómo puedo enviar sugerencia u obtener ayuda sobre un fallo?

¡Nos encanta que nos informes de fallos, sugerencias de características o cualquier otra idea! Por favor, pásate por la página de problemas en GitHub para buscar problemas existentes o informar de uno nuevo. Aunque tratamos de hacer un seguimiento de los problemas aquí, en el foro del plugin, obtendrás una respuesta más rápida (y se reduce el esfuerzo de duplicación) manteniendo todo centralizado en el repositorio de GitHub.

¿Cómo puedo colaborar?

Estamos llamando a este proyecto editor “Gutenberg” porque es una gran empresa. Estamos trabajando en ello todos los días en GitHub, y nos encantaría que nos ayudaras a construirlo. También puedes enviarnos tus comentarios, lo más fácil es unirte a nosotros en nuestro canal Slack, #core-editor.

Ver también CONTRIBUTING.md.

¿Dónde puedo leer más acerca de Gutenberg?

Reseñas

Gutenberg is a Downgrade

I like the idea of blocks, but Gutenberg should be an improvement to the current editor. It’s seriously basic and not really user-friendly. It should have lots of bells and whistles that make it appealing, but it does not.

I can’t add color to my headers or change the color of a text link. This is basic stuff man!!! There are things I like about it, but they are small in comparison to what I don’t like.

I LOVE the current editor and would HATE it if you added Gutenberg to the 5.0 WordPress version. Please don’t do this – you will get too many complaints. I have installed the plugin only because I’m not a tech person and don’t want to be surprised by the change. I don’t really care for it and will hate the forced intrusion of this new editor. This should be optional like in the plugin – we have the option of classic or Gutenberg editor.

April Fools Joke?

Seriously, they are about to destroy the most popular CMS of our time and for what? Just to change things for the sake of changing? The team seems to have no concept of user feedback and are just zealously charging ahead with a HORRIBLE editor. This has some of the worst usability and issues I’ve ever seen in a software update, it’s a joke, it must be.

Please keep as plugin, don’t include in core

Simply unusable, and incompatible with other 3rd party builders. Please don’t include this in the core, keep it as a plugin. Nice idea, but seems like a disaster in the making for all my web clients and me using Divi and other builders.

The WP community is throwing a significant proportion of red flags about Gutenberg. Please listen. Let this cook for a much longer time as a plugin.

With other builders so well done and mature, I just can’t see how things will improve with Gutenberg, which doesn’t feel even remotely mature and polished. I can only see Gutenberg always being 5 steps behind and playing catchup to what other builders have already done very well.

I can see the big picture and I am looking forward to it.

A lot of people do not understand Gutenberg, it seems. Perhaps that is partially the fault of the WordPress team for not being very clear on their plans from the very start? Perhaps it is also because Gutenberg is not really an easy thing to explain.

Most people expect all the features of the popular page builder plugins to be present in the version of Gutenberg that ships in WordPress 5.0. However, that is not the point of Gutenberg. Gutenberg is intended to provide a strong core that will, in the long run, be capable of everything the page builder plugins can do and more, while also solving many problems with building websites using WordPress.

What do I mean? Well, consider this.

There are a lot of page builder plugins. They all have different APIs and backend code, with modules/widgets/whatever-they-call-them that work only in their builder, and nowhere else. The page builder plugins have become a bit bloated, in some aspects. They not only provide a page building framework on the backend, but also a UI for using it, and many modules that can be used in it, but nowhere else. Want to switch from one page builder to another? Get ready to have to rebuild your content and deal with the loss of all the custom modules that the previous builder had.

It sure would be nice if there was a common API that all page builder plugins could use, so that pages could use any page builder graphical interface, but they would all share the same backend core APIs, and the modules would not be tied to a single builder anymore.

Gutenberg solves that problem. You may not like the Gutenberg UI, but you do not have to like it to benefit from the potential unification of page building that it could bring. Page builders would now be more compatible, and a lot of stuff that is currently bundled into a single page builder plugin could be spun off into something independent of any single builder, because it would be using the common APIs provided by Gutenberg.

But that’s not all Gutenberg will help with. Remember widgets? Those are pretty nice, but sadly, they have becomes pretty unused lately since they are usually only usable in specific widget areas created by your theme. You can not use them anywhere you want on your posts or pages, which greatly limits their usefulness. Some page builders like Beaver Builder and Elementor allow using WordPress widgets in their page builders, which is nice, but it would be even nicer if using them outside of widget areas was supported in core. Additionally, it would sure be nice if the WordPress widgets and the modules from any given page builder plugin used the same APIs and were not built with two completely separate systems.

And then there are shortcodes. Those work almost anywhere, but they are not a very visual way of adding content to something. And neither are widgets, though they are slightly better as they do have a UI, while shortcodes have none. And speaking of which, why are shortcodes and widgets separate? It would be nice if there was a single sort of… “block” or something that could be used anywhere and superseded both of them. Gutenberg solves this problem. Blocks in the Gutenberg editor provide a visual editing experience that is a lot nicer than manually editing the text of a shortcode, and far more flexible and WYSIWYG than a widget.

And then there are metaboxes. Some metaboxes involve things that are part of the main post/page content. These metaboxes will be replaced by Gutenberg blocks as well. Other metaboxes involve stuff outside of the main post/page content, and some of these will be replaced by things like the custom sidebar APIs that are being implemented into Gutenberg right now, while others will also be replaced with blocks.

But wait, if something is affecting content outside of the main post/page area (think author bio at the bottom of a post, the comments section, or the post title header of a page), then how can blocks solve this problem?

Well, as it turns out, Gutenberg will be able to edit areas outside of post content in the future. Not at the 5.0 launch, but it is on the roadmap. Gutenberg will eventually make it possible to edit not just the content of posts, but the content of your footers, your sidebars, the layouts of the post title, featured image, post content, and comments section on your website, and in the process make it possible to build a website without using manually-created PHP template files, and reduce the need for specific themes (or make them almost entirely convenient packages of premade layouts that could have been made using the Customizer and Gutenber editor).

Gutenberg will provide a strong core builder system that will soon greatly enhance the WordPress website building experience, bring modular content blocks to the editor that are independent of any builder (like widgets did for sidebars, but with the ability to be used anywhere), and obsolete some page builders while turning others into extensions and alternative user interfaces for the core editor that all share the same common core APIs and prevent designers and developers from becoming stuck with any particular page builder plugin.

Will Gutenberg immediately do all of this at launch in WordPress 5.0? No, it will not. Gutenberg is being developed in phases, and the version in WordPress 5.0 will only be the result of the first phase. But in the long run, Gutenberg will change a lot about WordPress editing, and I am looking forward to that future.

If you can not use Gutenberg yet for whatever it is you do, then that is fine. You can still use the Classic Editor via the Classic Editor plugin, and you can still use your page builder of choice as well. In fact, Gutenberg does not mean the death of page builder plugins. If anything, I think Gutenberg will be able to make them more powerful.

Like I said before, in the long run they may adapt by becoming front ends for Gutenberg that look the same as they did before, but use a core set of APIs that allows you to easily edit the page in whatever builder you choose. Others may take an approach that is basically the same as most do right now and make their code pretty much completely separate from the core editor, providing their own edit screens for the WordPress admin that simulate what they look like right now with the Classic Editor. Still others may integrate (at least initially) with Gutenberg by creating blocks for the Gutenberg editor that are basically embedded instances of their builder. (That is what SiteOrigin is doing.) There are a lot of opportunities for integration and improvement.

As for compatibility, I am really not that concerned. WordPress 5.0 will load the Classic Editor if it detects a plugin incompatibility, and the Classic Editor plugin will be available to force usage of that editor when necessary. Additionally, Gutenberg has been continually improving its compatibility with metaboxes, and many plugins have been working to add support for Gutenberg. The Gutenberg editor even provides a Classic block that is basically an embedded version of the TinyMCE editor box in the Classic Editor, in order to ease the transition for older content into Gutenberg.

One more note I would like to make is that a lot of people think Gutenberg should provide every formatting option possible by default. But in my opinion, WordPress is supposed to provide a strong core that can easily be extended with whatever features you want. Gutenberg will allow that. Yes, you can not color text inline in a Paragraph block. (Well actually you can using the “Edit as HTML” option.) But you can just use a plugin that adds that option to the block. And perhaps if the plugin is installed by a large number of people, the WordPress team will decide it must be a greatly wanted feature and add it to core. But Gutenberg should not be judged by how many options it has by default. It should be judged by the core interface, the ability to extend it, and whether it provides good default features or not.

Since I have been pretty positive throughout this review, I think I’ll end with my concerns. I do not know when Gutenberg will be merged into core. I am not even sure the developers know just yet. Stating a hard deadline would probably not be a good idea, or at least not yet. Gutenberg still needs some polish, and it needs more user testing to determine which areas of the UI and UX need improving.

There has been some backlash against the idea of putting a notification in WordPress in the next minor update for users to try out the Gutenberg editor, but I feel like that will be necessary sooner or later in order to get a good sense of what still needs to be improved before the merge proposal. I would not want Gutenberg to be released too early and with too little user testing.

If I had to guess, Gutenberg will not be ready for a merge proposal until at least late May, and I would not be surprised if it happened in June. Development of Gutenberg has been rapid, and improvements have been a lot faster than you might think, but I am not sure it is fast enough to be ready until at least a month from now. The milestones on the GitHub page show several things that need to be completed before a merge proposal is considered, and it seems like they are sticking to that. They do not seem to be in too much of a rush to get the editor into core. I just hope there is enough user testing that happens between now and when the merge proposal happens. Of course, the WordPress 5.0 beta will bring tons more testers, but it would be nice if the majority of UI and UX issues are resolved before then.

Speaking of user testing and feedback, I recommend posting issues on the GitHub page for Gutenberg concerning the issues you are experiencing (whether technical bugs, conceptual concerns, or things you do not like about the graphical interface), as well as checking out and commenting on the existing issues. The best way to have a say in what is going on is to go there and say something.

https://github.com/WordPress/gutenberg/issues

Finally, I would like to make a note about the star rating I chose. If I were to rate this based purely on what the plugin does right now and this very moment, I would give it 3 stars. But I can not act like this is all that Gutenberg will ever be or all that is currently planned to be. The Gutenberg project as a whole is a lot bigger than what this plugin does right now, and I will not be able to rate later versions of Gutenberg after it gets merged, so I am rating it right now with the understanding that this is a beta plugin for the first phase of a huge long-term project that I think will revolutionize how people build websites with WordPress. And as the first step of something as big as this, I think this is really well done. The biggest issues it has are user interface and user experience problems that require a lot of user testing to fully resolve, and the odd bug here and there that is being worked on and is to be expected from a beta plugin. The core concepts, plans, and extensibility of the project are great, in my opinion.

Well, that is what I think of Gutenberg. I hope my review was helpful and insightful for you.

Appreciate the Work and effort but I have a request

Would be possible to have the editor with 100% width of the contents area width, this way I can see my contents displayed in its full width of the front end content area given width, this also will help me when I build my own custom blocks so my users will see how their contents will be displayed while they are editing it in the editor

Leer todas las 447 reseñas

Colaboradores y desarrolladores

“Gutenberg” es un software de código abierto. Las siguientes personas han colaborado con este plugin.

Colaboradores

“Gutenberg” ha sido traducido a 26 idiomas. Gracias a los traductores por sus colaboraciones.

Traduce “Gutenberg” a tu idioma.

¿Interesado en el desarrollo?

Revisa el código , echa un vistazo al repositorio SVN , o suscríbete al log de desarrollo por RSS .

Registro de cambios

Latest

  • Add pagination block (handles page breaks core functionality).
  • Add left/right block hover areas for displaying contextual block tools. This aims to reduce the visual UI and make it more aware of intention when hovering around blocks.
  • Improve emulated caret positioning in writing flow, which places caret at the right position when clicking below the editor.
  • Several updates to link insertion interface:
    • Restore the “Open in new window” setting.
    • Remove the Unlink button. Instead, links can be removed by toggling off the Link button in the formatting toolbar.
    • Move link settings to the left.
    • Update suggested links dropdown design.
    • Allow UI to expand to fit long URLs when not in editing mode.
    • Improve visibility of insertion UI when selecting a link
  • Rework Classic block visual display to show old style toolbar. This aims to help clarify when you have content being displayed through a Classic block.
  • Add ability to edit post permalinks from the post title area.
  • Improve display of image placeholder buttons to accommodate i18n and smaller screens.
  • Add nesting support to document outline feature.
  • Refactor and expose PluginSidebar as final API.
  • Refactor and expose SidebarMoreMenuItem as part of Plugins API.
  • Simplify block development by leveraging context API to let block controls render on their own when a block is selected.
  • Add ability to manage innerBlocks while migrating deprecated blocks.
  • Add a “Skip link” to jump back from the inspector to the selected block.
  • Add preloading support to wp.apiRequest.
  • Add isFulfilled API for advanced resolver use cases in data module.
  • Add support for custom icon in Placeholder component.
  • Disable Drag & Drop into empty placeholders.
  • Refine the UI of the sides of a block.
  • Assure the “saved” message is shown for at least a second when meta-boxes are present.
  • Make sure block controls don’t show over the sidebar on small viewport.
  • Add ability to manually set image dimensions.
  • Make Popover initial focus work with screen readers.
  • Improve Disabled component (disabled attribute, tabindex removal, pointer-events).
  • Improve visual display of captions within galleries.
  • Remove default font weight from Pullquote block.
  • Keep “advanced” block settings panel closed by default.
  • Use fallback styles to compute font size slider initial value.
  • Allow filtering of allowed_block_types based on post object.
  • Allow really long captions to scroll in galleries.
  • Redesign toggle switch UI component to add clarity.
  • Improve handling of empty containers in DOM utilities.
  • Filter out private taxonomies from sidebar UI.
  • Make input styles consistent.
  • Update inline “code” background color when part of multi-selection.
  • Replace TextControl with TextareaControl for image alt attribute.
  • Allow mod+shift+alt+m (toggle between Visual and Code modes) keyboard shortcut to work regardless of focus area and context.
  • Allow ctrl+backtick and ctrl+shift+backtick (navigate across regions) keyboard shortcuts to work regardless of focus area and context.
  • Improve Classic block accessibility by supporting keyboard (alt+f10 and arrows) navigation.
  • Apply wrapper div for RawHTML with non-children props.
  • Improve and clarify allowedBlockTypes in inserter.
  • Improve handling of block hover areas.
  • Improve figure widths and floats in imagery blocks, improving theming experience.
  • Eliminate obsolete call to onChange when RichText componentWillUnmount.
  • Unify styling of Read More and Pagination blocks.
  • Replace instances of smaller font with default font size.
  • Fix styling issue with nested blocks ghost.
  • Fix CSS bug that made it impossible to close the sidebar on mobile with meta-boxes present.
  • Fix disappearing input when adding link to image.
  • Fix issue with publish button text occasionally showing HTML entity.
  • Fix issue with side UI not showing as expected on selected blocks.
  • Fix sticky post saving when using meta-boxes.
  • Fix nested blocks’ contextual toolbar not being fixed to top when requested.
  • Fix centered image caption toolbar on IE11.
  • Fix issue with meta-box saving case by only attempt apiRequest preload if path is set. Also improve tests for meta-boxes.
  • Fix JS error when wp.apiRequest has no preload data.
  • Fix regression with image link UI, and another.
  • Fix regression with columns appender.
  • Avoid focus losses in Shared block form.
  • Fix ability to select Embed blocks via clicking.
  • Fix handling of long strings in permalink container.
  • Fix resizing behavior of Image block upon browser resize.
  • Show Image block with external image URL and support resizing.
  • Fix hiding of update/publish confirmation notices under WP-Admin sidebar.
  • Fix ID and key generation in SelectControl and RadioControl components.
  • Fix z-index of link UI.
  • Fix default width of embeds in the editor.
  • Revert unintended changes in default font size handling on Paragraph.
  • Disable the Preview button when post type isn’t viewable.
  • Remove unused variable.
  • Rename “advanced settings” in block menu to “block settings”. Update labels and docs accordingly.
  • Improve description of embed blocks.
  • Default to empty object for previous defined wp-utils.
  • Finalize renaming of reusable blocks to shared blocks.
  • Update 20 components from the editor module to use wp.data’s withSelect and withDispatch instead of react-redux’s connect.
  • Update another batch of components from the editor module to use wp.data’s tools.
  • Replace remaining uses of react-redux in the editor module.
  • Update a batch of core blocks to drop explicit management of isSelected thanks to new context API.
  • Attempt to avoid triggering modsec rules.
  • Use wp-components script handle to pass locale data to wp.i18n.
  • Reference lodash as an external module. This also reduces bundle size.
  • Use border-box on input and textarea within meta-boxes to restore radio buttons to normal appearance.
  • Clarify demo instructions on wide image support.
  • Update docs to address broken sketch file links.
  • Reduce and rename rules in Gutenberg block grammar for clarity.
  • Add test confirming that withFilters does not rerender.
  • Allow E2E tests to work in a larger variety of environments.
  • Add mention of JSON workaround to including structured data in attributes.
  • Document use of GitHub projects in Repository Management.
  • Fix some documentation links.
  • Add accessibility standards checkbox and reference to the project’s pull request template.
  • Remove emoji script as it causes different issues. Pending resolution on how to introduce it back.
  • Avoid needing navigation timeout in Puppeteer.
  • Disable login screen autofocus in Puppeteer tests.
  • Allow developers to opt out from some devtool settings to speed up incremental builds.
  • Use the WordPress i18n package and remove the built-in implementation. Update to 1.1.0.
  • Remove deprecated function getWrapperDisplayName.