Ideas for Gutenberg and WordPress future

[ghost]

What problem does this address?

Pain points to be explored by WP teams on their activities.

What is your proposed solution?

Hello! As a fan of WP, I enjoy design PRs. I read them now daily as a hobby simply to know what's to come on the Gutenberg project. =) (even though I am not a skilled developer.)

The latest WordPress updates were great, and WP is harvesting its crop. WP5.8 is coming ahead with awesome features. Template editor and new dynamic blocks for the first time are going to enable users to do things that always were meant to be simple. Those new features reduces the temptation to migrate from WordPress to simple no-code-block-editors that allow creating a website slightly above the blog scope.

I really appreciated your friends' efforts regarding translating many WP functions into the new dynamic Blocks. Because we are not going to need to code those functions anymore. I remember a GitHub PR from carolinan on previous weeks which in a table made this comparison clear to understand. It showcased for example: the new login/logout, site title, site logo,... and other blocks were translating many single functions.

Other no-code-editors remain doing better than WP with easy and simple implementations for the casual user regarding making it available every single function as a block (or as a workflow, action triggered as a link inside a block). This is the limitation of WP today and its great potential in the coming years. I am going to describe it in more depth:

If today I wanted to dynamically retrieve biographies and websites-links from the profile of 5 users, inside of a post, I would not be able to do it without resorting to the use of some code-functions, or defining one by one author blocks. This ineffective action doesn't improve maintenance of posts, and doesn't scale beyond the blog scope, which is just WP's entrance. It makes no sense inside the block editor to remain retrieving data with an extended step by step logic, as if exposing users biographies represented accessing an external database/API service. In fact, those are the users from the same website: how to dinamically mention and showcase them inside a post, with blocks, in the expected way? It is just a demand which requires WP to showcase its structures, not plugins. Well structured way to access informations from other parts of the same system. Currently, to achieve this objective I would need to make use of custom shortcodes plus PHP functions, which by the way are not properly supported inside the block editor. Appreciation would I feel if in the future, most of each single and disconnected WordPress functions could become available inside the block editor, not necessarily as a block, but as its appropriate visual form: either as a workflow, or as an action/link/query option, as in fact those functions are to be seen and applied. The easier, the better, just as other editors are doing. It does not mean to turn the block editor into an advanced editor (many of the block editor's advanced preferences are currently hidden on a popup.)

There is great potential in exploring bringing old and disconnected WordPress implementations towards inside the block editor. For example: for what use are: 1. a well developed user role and capabilities system; 2. the custom fields system; and 3. the block editor system, if none of them are integrated to each other inside WordPress? Some years were necessary to be able to choose CPTs (a fundamental part of WP) inside the query block, but we still cannot edit those same CPTs(!?) in a proper, simple and default way. The way they talk about it, it seems that WordPress is in fact the plugin territory, or shy of itself, when not even its own well-made feature is presented to the world! The user role system was created to consider user capabilities, but I cannot edit them (!?).

When each of these absences are solved with plugins (User role editor; ACF), individual solutions become available, but suspended remain the possibilities in which WordPress could better serve its users and devs if integrated were its micro-systems. For example: it is unavailable today the opportunity to retrieve a custom field value inside a post as with a custom-field-block. Instead, the solution remain outdated, as a metabox positioned below the post which retrieves the value to be dealt by an external template or code function. More proposition: what about a custom field block, which retrieves a value which is only going to be read by the user from a certain "block-supports-user-role" user role? This is an unexplored limit between ACF and User Role Editor, which could have been done and made extendable by WP in the first place. Does it need to be difficult? To end this pargraph, I would like to mention that old talk about limiting the post visibility not only by private or by password, but also by default and custom user roles. How much the ecossystem can mature inside the block editor. I hope it won't take years to integrate user roles as an option on the loop query block, for example.

WordPress should shine because it can! It was built on small pieces of features, and just now it is connecting them by building its macro structure, global-systems (for example: the template editor, the global styles). I hope every other part of WP follow this example. If user roles and permissions were to become a first class system, suddenly a membership-website-administrator would be able, inside a block page, to showcase to users their informations regarding CPTs and user roles permissions. Similarly to "Site Title Block", it would be able to add a "Current User Role Title Block", or "User Posts Quantity Block".

In a similar way to Global Styles, Global Permissions would allow administrators and post editors to easily adjust which user can see each other photos on media library; or which user can send files to the media library using the "File Block" on a post. What about if custom field values can be stored to a CPT in the same way that File Uploaders like the File Block can store custom fields to media libraries? On and on, basic possibilities emerge arise from systems integration!

The incoming dark mode could not only be implemented from the theme's perspective. In order to enable a "Dark Mode Toggle Block", what about considering it as an user setting too? Save the user preference when they toggle dark mode! Associate that preference to the "User profile Block". You see? It is not only about dark mode reflecting changes on the WP-Admin palette... Integrating these systems are always going to be difficult if WordPress remain being a conglomerate of different systems never talking to each other because of the absence of the "global settings" regulating and expanding the puzzle. "Setting-supports" could be a mirror of "Block-supports" .json mindset. Now that Global Styles is becoming reality, just see how all innovation is coming together, and old disconnected pieces are finally becoming relevant and easier to adjust from users, admins, themers and devs perspectives.

What I miss from the block editor currently is: how are we able to extend core blocks without applying code? For example, the need to retrieve an user profile photo from Gravatar requires functions, hooks and so on. It is difficult for me to code. Among the countless options, I can choose to get a Gravatar on a certain dimension, or I can request a gravatar pic from a custom field link retrieved earlier inside the function. On and on, plugin developers extend these functions. But inside the block editor: firstly, there is no gravatar block mirroring the existing functions and its options. Secondly: how would we be able to extend a gravatar block, in the sense of fulfilling, for example, that objective of requesting a gravatar according to a custom field value informed somewhere else (maybe retrieved from the "Post Title block" on this page, for example?) Those are the scenarios in which dynamic blocks are not enough, because they remain independent. And that happens because dynamic blocks are unable to integrate WordPress tentacles when WP itself doesn't fix this. Improving WP requires thinking ways of grouping functions inside a Workflow popup or a visual-block similar to how the Query block is implemented with its loops.

Although the potential to be explored is regarding bringing dynamic and old systems together into the block editor, limitations to static core Blocks is also in need to be unlocked.

As far as I know, the design team is building components for internal use. Can we extend mindset to the block editor too? Currently, theme developers and users cannot make use of the accordion 'component' (block!). Other example: regarding easily inserting Icons on a post, there is block for that. Meanwhile, strangely WordPress is embedded with dashicons/svg icons, and none are available for use inside the block editor!).
I am not writing about complex blocks and scenarions which require introducing new systems and components; instead, I am writing about properly and simply exposing/potentializing what has already been carefully done.

I cross my fingers for the refactored table block, the refactored gallery block, and the refactored TOC block. From a user perspective, those are our components.

I encourage you to keep on working on the Block editor's Preferences modal. See, the structure is there. Enabling and disabling features for more contexts and user cases currently showcases many options, however don't you agree it is strange how limited and repetitive those options are when we remember ourselves that beyond the block editor perspective, we are inside a powerful system (WordPress)?

For a future in which the depth of the system is explored. For a future in which WordPress collapses to its own strength. For a future in which a user do not touch code for shortcodes, a theme developer do not touch code for functions, a developer do not touch code for hooks, and a site administrator do not touch in limitations of the WP-management-systems.
Please, if this post matters to you, contribute to the community and share this post to your people or debate on the appropriate channels.
Thank you.

[jasmussen]

There's a wealth of enthusaism and ideas here, thank you. I've added a label so it's easier for folks to find and perhaps chime in on.

For a high level thought: there's a lot of work to still be done on many aspects of the block editor, on the writing flow, on block extensibility, on template editing. Roles and user flows can bring big improvements, and is something we should look at in the future. It is, as you say, the greatest strength of WordPress that it is so versatile. But there's more work to do. Remember, for every one item we fix, we're one step closer. Keep going!