How the WordPress Block Editor Changes the Conversation for Content Editors and Developers (WordCamp Long Beach 2019)
•Descargar como PPTX, PDF•
1 recomendación•268 vistas
Everyone in the WordPress community is talking about the new editing experience in WordPress. Wherever you fall in defense of or against the new editor, it changes how we interact with WordPress from a content editing and a development perspective. In this talk I will explore some of the ways Gutenberg changes how we build things as well as the types of things we can build to enhance and improve the WordPress editing experience.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (18)
Más de Chris Reynolds
Más de Chris Reynolds (10)
Último
Último (17)
How the WordPress Block Editor Changes the Conversation for Content Editors and Developers (WordCamp Long Beach 2019)
Notas del editor
- hi this presentation is not overly technical but will get into some technical things resources and approaches for developers starting out in gutenberg development things for content editors and site administrators to know about working with gutenberg and also having those conversations with developers this presentation was built almost entirely in gutenberg to show the different types of things that can be done
- hi this presentation is not overly technical but will get into some technical things resources and approaches for developers starting out in gutenberg development things for content editors and site administrators to know about working with gutenberg and also having those conversations with developers this presentation was built almost entirely in gutenberg to show the different types of things that can be done
- Block editor added in WordPress 5.0 2 years of development React-based editor Entirely built on top of the WP REST API Now referred to as “block editor”
- Over 10,000 commits Over 400 contributors Over 1200 releases * significant development and person-hours involved in this product
- What problem is the block editor trying to solve? * WP admin hasn’t been updated in years, losing ground to more intuitive editorial interfaces like Squarespace and Medium
- WP has outgrown TinyMCE
- Full control over page layout in WP has been difficult, requiring editors to learn and remember shortcodes, use third party tools like Shortcake, or page builder tools like Beaver Builder and Visual Composer to solve those problems
- pull quotes
- columns
- tables — previously would have required knowledge of html or copy/pasting from a spreadsheet
- Like the Customizer, the block editor establishes a standardized toolset for adding editorial components
- First major internal component of WP built almost entirely in javascript. * Uses React * some licensing concerns about that * React is maintained by Facebook, some ideological and maintenance concerns around that * React was chosen over Vue, a smaller, more independent library, some philosophical concerns around that * Pretty steep learning curve for both javascript, generally, and react specifically * Forward-thinking architecture -- uses ESNext / JSX * React can be ripped out if needed, and WP-specific wrappers are used for most things Modern, block-based editor for more control over dynamic layouts and content types within posts First time significant attention and development has been spent on a UX component of WordPress Accessibility * While individual parts of the block editor might be accessible, Gutenberg was not developed from an accessibility-first standpoint, which led to many accessibility fixes being handled as an afterthought * Many tasks are extremely difficult and painful to do with a screen reader * Keyboard shortcuts exist but it’s not always clear how to get to them * Individual blocks will only be as accessible as the developers make them
- Technical implementation differences json array of attributes * stored in the database all markup is saved in the editor wrapped in html comments * those html comments are not rendered in the front-end
- another example, full width cover image
- wrapped in html comments defining the type of block and a json array of attributes attributes include the image url, alignment, attachment id those are then used in the rendered markup alignment informs the class used, url and attachment id determine the background image url all the actual markup is standard html divs, p tags, things a browser would recognize even if your theme doesn’t support the classes, it will at least display something that looks something like what is supported and if your theme doesn’t support the classes, you’ll see what that looks like in the editor, so it’s not a surprise when you hit publish
- There’s a classic editor block if you don’t know what to use or don’t want or need the Gutenberg flow this works the same way you’d expect, hitting enter starts a new paragraph within the classic editor block rather than opening a new gutenberg block
- You need to search for the block, but if you’re using it frequently, it’ll float to the top of your Most Used blocks
- The actual markup is exactly what you’d expect — no additional gutenberg block markup at all.
- If you absolutely don’t want to work with gutenberg or your site’s not ready to make the switch, the classic editor plugin is available a bit of an end-of-life for the plugin as it’s only expected to be supported until 2022 it may be maintained and supported longer, but by that time, plugins and themes may move beyond supporting the classic editor and you’ll start to see compatibility issues there
- ClassicPress is a hard fork of WordPress prior to 5.0 that only uses the classic, TinyMCE editor
- What do I need to know as a developer to start working with the block editor?
- I’ll tell you a couple things you don’t need to know. You don’t need to know React — but it helps You don’t need to know ES6 or ESNext — but it helps a lot Gutenberg was written in React and ESNext so it helps in understanding the core modules if you are at least partially familiar with these languages. But blocks can be written in vanilla javascript and ES5. Making use of ESNext syntax and JSX is a lot more intuitive and easier to learn that I had anticipated All the React components used have WordPress-specific wrappers so you’re not interacting with React itself very frequently (outside of core development)
- Zak Gordon’s Gutenberg Block Development course is a huge asset this course will go over some of the JSX and ESNext syntax used in gutenberg block development
- hm-gutenberg-tools Tools and components that can help in Gutenberg development
- Gutenberg Starter Kit
- Gutenberg plugin boilerplate with example code
- Hot Module Replacement for Gutenberg Hot Module Replacement allows components to update live on the page as you make changes to the code and the code is compiled This is a huge asset to Gutenberg development If code is out of sync, Gutenberg will often break during development — this solves that problem so you don’t constantly have to reload
- It’s a long read but it’s pretty comprehensive and explains how we’ve used it on multiple projects
- HMR built into webpack-helpers library which simplifies the build and configuration process for both gutenberg and non-gutenberg development
- There are some general philosophies for developing blocks
- You are developing for the admin rather than the front-end For those of us who consider themselves “back end developers”, this is a pretty big context-shift Things that were previously handled with shortcodes should probably be Gutenberg blocks But it’s not a 1:1 conversion -- user interaction and experience needs to be more fully considered Metaboxes should be re-thought Many places a custom metabox was used might be better served inline with an interactive Gutenberg block Stronger emphasis on “what you see is what you get” All the styles used in the admin to render your block should be the same as those used on the front-end
- What do I need to know as an editor using Gutenberg?
- You have blocks! Consider the experience of OEmbed in the WordPress editor as a comparison For bespoke projects, you will need to be clearer about your requirements The specific interactions can be highly individualized, which means far more clarity will be needed when considering implementation Gutenberg blocks take longer to develop Whereas previously, a custom metabox or shortcode could be developed in less than a day, expect several days worth of development for a similar Gutenberg block...at least as your development team is getting familiar with the tools and the workflow But it’s worth it You can do things in a gutenberg block that simply weren’t possible before
- Some ideas off the top of my head of things that could be built in Gutenberg
- Translations A translatable text block could be created that allows direct translations to be handled inline Embeddable contact and newsletter signup forms Customizable fields can be added or not Featured content A pull-out highlighting content somewhere else on the site Logic can be contextual or manually curated Ads and third party embeds Ad placement and embeds can happen inline within the editor, so content editors always know where these things will display on the page Placement can be manual or through automated logic A/B testing A block or series of blocks could be created to test out different content or design strategies Nested blocks Blocks inside blocks inside blocks
- Publication checklist require a series of actions to be completed before a post can be published built into Altis configurable from a code level (users/administrators don’t have control over checklist items by default)
- Closer look at the dialogs lists the tasks that still need to be comleted displays a warning if actions have not been completed (and an option to ignore and publish anyway)
- Reusable blocks at scale taxonomies to blocks, so blocks can be organized by section/topic reusable block suggestion and search — make it easier for people to find reusable blocks tracking reusable block usage — there’s currently no implementation of this permissions around who can create reusable blocks — all editors/authors should not necessarily be able to create reusable blocks purge — if all reusable blocks of a particular type need to be removed (e.g. for legal reasons), they can all be removed in one action retire — if reusable blocks shouldn’t be used, but don’t need to be purged, make it so they cannot be used/added
- any questions?
- Zak’s G’berg block development course HM repos HM article on HMR HM has written a white paper about Gutenberg and what it can do