Will the full site edition land in WordPress 5.8? A decision is coming – WordPress Tavern


Yesterday, Josepha Haden Chomphosy announced the roadmap to decide if the Full Site Edition (FSE) will land in WordPress 5.8. Following the launch of Gutenberg 10.4 on April 14, a small group of industry leaders will participate in a go / no-go demo.

The following people will be on call:

  • Matias Ventura – Gutenberg Project Manager who will animate the demo.
  • Matt Mullenweg – WordPress Project Manager.
  • Helen Hou-Sandì – Senior Developer.
  • Josepha Haden Chomphosy – Executive Director.

The meeting agenda is simple. Ventura will host the demonstration, and the group will discuss and cover implementation issues.

If there are no blockers, they will share a plan to merge FSE into WordPress. The most likely outcome is that they will find at least a few things that need to be addressed. In that case, they’ll share them publicly with a plan to address them before a second no-go date on April 27.

The first beta of WordPress 5.8 is scheduled for June 8, with a consumer release for July 20. The team should decide on inclusion early in the release cycle to give theme and plugin developers time to prepare.

While many are on their toes awaiting a final decision, everyone should have a little patience for now. Everything must be carefully weighed by the project managers. There’s a good chance we won’t know the outcome until that second deadline of April 27th.

Most of the FSE transition would be a beta run for a subset of users. Including these features in the kernel doesn’t mean WordPress immediately flips the switch and turns everything on for 40% of the web. For the overall FSE experience, users must make an explicit choice to install and activate a block-based theme.

With that in mind, the onboarding experience should be welcoming that invites users to modify the site while letting them know about potential issues. If it is a built-in beta, they really need to understand that improvements are coming.

A built-in beta like this is also welcome, given the Block Editor project launched a few years ago. No matter if people liked or hated the Block Editor, the deployment wasn’t easy for everyone. WordPress has plunged end users into a revamped system, which has been a shocking change for many. The project has a chance to do better this time around by gradually introducing features to users and allowing others to immerse themselves in the new experience of their own choosing.

“The most important context to share is that it is not delivery as the default full experience for usersChomphosy wrote in the post, noting that the team is growing beyond the mistakes of the past. “One of the clearest feedback from the Phase One merger process was that our plugins (agencies, theme authors, plugin developers, site builders, etc.) did not have enough time to prepare for the changes. to come up.”

Decision makers may also decide to ship some parts but not others. FSE is a project made up of several components.

“The whole full site editing project is sort of a generic term for a collection of tools and projects, so it would be possible for some parts to be shipped while others not,” he said. said Haden Chomphosy. “There are probably a few exceptions to this, as you mentioned, but a lot of them can be shipped as soon as they’re ready.”

The exceptions she was referring to are things that make more sense together. For example, block-based themes via a theme.json config and most site edit blocks are not as useful when separated.

Of course, there are cases where something like the Query block could be used outside of the site editor. Users can create custom queries on a page without benefiting from the site editor, for example.

My main concern is not the functionality related to the site editor, but the block-based widgets. It is a transition tool for users on traditional themes. With the new navigation menu screen, it’s not part of the block-based theme experience. The goal is to allow users to start using blocks in more places. However, this will cause the UX to break in many cases.

The widget experiment is still partially interrupted, treating each block as a separate widget. Users should learn how to put a title (widget title) and another block (widget content) in a group (widget wrapper) for the appropriate classes related to widgets on the front end of the site. For some themes, it won’t be a problem for users to do this. To others, it will look ugly at best and break the layout at worst. Putting this responsibility on the shoulders of end users was considered an acceptable solution.

I wanted to focus on this issue because it’s one of those things that can just be reversed for all users. I’m always worried that the transition from a working system to a potentially broken one will lead to a bumpy ride.

The WordPress 5.6 release team has decided not to ship block-based widgets. Hou-Sandì, as the core tech lead for version 5.6, provided a historical account of the decision and why it was not ready for inclusion:

My question for the features that affect the front end is “can I try this new thing without risking ruining my site?” – that is, the trust of users. Right now, since widget areas aren’t displayed like what you see on your site without the themes really putting some effort into it, and you have to save your changes live without revisions to get a real contextual view, widget area blocks do not. let you try out this new feature without penalizing yourself for experimenting.

While the widgets have no doubt improved, I still see the answer as being the same as last October. I haven’t seen enough membership from the theme development community to support the block editor itself, let alone the new block-related features. However, at some point the project just has to move forward. They will just need to keep pace.



Source link

Comments are closed.