WordPress as a CMS and application platform

[TonyGravagno]

I'd like the following points to be conveyed and clarified in a blog that clarifies the positioning of Gutenberg in the world of WordPress Development.

• Common references to WordPress as a CMS go to the extreme of making the platform "headless". That's not necessary. The browser tooling is ideal to support a business application in terms of user management, permissions, review and edit of submissions, notifications, and so many other features, whether core or plugin-supported. Application-specific components can then use WP in a headless mode via the REST API - all together as an integrated platform.
• It's tough to find React/WordPress documentation that doesn't conflate with Gutenberg and blocks, which is focused on back-end development. WordPress pages and related menu navigation can serve as a routing framework for front-end application components created with React, TypeScript, wp-element, and related tooling.
  • Note that the developer documentation for Components, Packages, i18n translations, and other great application tooling is all located within the Block Editor Handbook!
• Document approaches to specific types of React application navigation, which is usually managed with a Router, within the WP front-end, which requires special handling for such routing.
• Provide examples for usage of WP-specific features in a React app hosted in a WordPress page. For example:
  • @wordpress/compose : "a collection of handy and you can use to wrap your WordPress components and provide some basic features like: state..."
    • For state management, when might we use the above @wordpress/compose package compared to other common tools like useState or useMemo?
    • Might there be reason to prefer using WP Transients rather than useContext? Is there an equivalent in Compose?
  • @wordpress/element : "Element is, quite simply, an abstraction layer atop React".
    • Most tutorials that describe an interface with WordPress still include "import React from 'react'". Do we encourage usage of the Elements package instead of that? Why?
  • @wordpress/components : "Usage: Within Gutenberg, these components can be accessed by importing from the components root directory"
    • What if we're not creating a Gutenberg block? Does this community recommend usage of this Components package for front-end development?
    • What is different between this huge collection of wrapper components and the Material UI library? MUI (see Components)
  • @wordpress/hooks : "A lightweight & efficient EventManager for JavaScript."
    • This is actually an amazing package that brings the functionality of PHP out to JavaScript. It seems foundational to writing entire plugins in JavaScript (for those who "Learn JavaScript Deeply").
    • For people who say "I can't write code for WordPress because I don't know PHP", this is the entry-point to allowing a JS/TS developer to do most of their coding outside of PHP.
    • This is the bridge for people who do write PHP to port some of their code client-side, to learn JavaScript using familiar functions.
    • This is the starting point where we might eventually be able to say "that's OK, you don't need to know PHP to write code for WordPress".
      • And yet, there's hardly a mention of this in places where developers go to learn about modern development with WP.
• Can we describe a block in terms of a front-end component which can be assembled with other such components to assemble an actual application?
  • A simple example might be a Form block, and a library of blocks that each wrap one of the @wordpress/components. Drop the Form block in a page, add components as children, like Panel, TextInput, and Button. Add a Submit block that processes submission of the form to populate a CPT, or maybe save the data to a Google Sheet. Each of these functions might be equivalent to a JSX component, which at run-time operate like any other React application.
  • The concept of building an application from a set of components is not new. It's the foundation for all of these "build your mobile application online" tools.
  • The difference between what I'm describing here and what we do now with blocks, is that application blocks are all integrated with code that defines context between them, while content-oriented blocks are mostly intended for presentation, and have few or no inter-relations with other blocks.

With guides to using the existing @wordpress/* tools for front-end application development, perhaps the exact same mechanisms can be used for creating plugin admin pages and other plugin functionality.

Ultimately the point here is that we have talked about using WordPress as a CMS since v3, but all Gutenberg focus seems to be on blog and page creation, and FSE. We still discuss it and develop for it like it's a blog package. Perhaps I'm missing a main concept, that "Gutenberg" and "blocks" are not just about the back-end, blog and page maintenance, Full-Site Editing, and maybe admin plugins. But as a consumer of WordPress Marketing, that's sure the message I'm getting - until we start to see consistent, emphatic notes like "yes, of course Gutenberg is intended to be used as a part of all front-end application development!"

I'd hope that with a new blog on this topic (or series of them) we can open doors to creativity, where people can envision using the packages that exist now, create more like them, and create more applications that are integrated seamlessly with the WordPress front-end.

[bph]

Thank you @TonyGravagno This is some major thinking and writing in your post. I'll have to read it again with fresh eyes in the morning, but I am very intrigued. It goes beyond the building blocks within and more using Gutenberg as a framework. Breaking it down by scripts with concrete use cases would certainly make for some fantastic education.

With guides to using the existing @wordpress/* tools for front-end application development, perhaps the exact same mechanisms can be used for creating plugin admin pages and other plugin functionality.

Strongly agree with you, that would make the interface's mish-mash users have to relearn with every plugin they isntall, so much more standardized and with that also faster to develop, as most decision have already been made.

There is a course in Learn WordPress site that is a great start, but it's also a basic tutorial, to introduce the idea Using the WordPress Data Layer