As you may know, the “Full Site Editing via Gutenberg” is the main goal for 2021. We still don’t know when exactly it will become the part of core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. but to avoid missed opportunities (as we had them in the past with Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/) let’s start preparing documentation space for this new feature’s arrival.
We want to join efforts with other teams already working on Site Editor. Namely, the Test team has an ongoing Outreach Program (lead by @annezazu), Themes team (mostly @poena) is explaining what this feature is and how it’s working, Core and Design teams are building it: pull requests and issues.
Our job is to document it.
First things first
Before we start with anything else, we need to know two things: the name and the place.
The name
It’s been called “Full Site Editing” throughout the community but, as history teaches us, this is most likely to stay around only as the code name for the project, used among people working on it.
We will probably have a different name facing documentation consumers so, to avoid confusions and to have a proper Handbook slug from the beginning, we might want to spend some time on thinking it through. This is not a task only for the Documentation team, of course, and we hope to get input on this post from all teams involved.
It’s been suggested in #docs chat, that “Site Editor” might be an appropriate name (just as Gutenberg became Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor) so we’ll use it as a starting point. Please leave your opinions and suggestions in the comments below.
The home
The whole user facing documentation is roughly divided into end user documentation (HelpHub) and developer documentation (DevHub). Obviously, Full Site Editing feature should be explained to both, in a way that is useful to each group.
@bph is already doing an amazing job in organising and creating content for end user Block Editor documentation and she has a plan for Full Site Editing feature.
The problem we are facing is the home for developer part of Full Site Editing feature documentation. It doesn’t fully belong to any existing Handbook as it requires features from different areas (it needs to be enabled in theme but it assumes template post types, it doesn’t create new blocks but it does use blocks specifically created for it, it can use global styles etc).
Majority of the Documentation team agrees that Full Site Editing feature shouldn’t be buried in any one existing Handbook but it should be mentioned where relevant. Also, we agree that the full concept should be explained in one place from and to where we can easily inner link relevant places in other Handbooks.
Considering there might be much more to Full Site Editing feature in the future and we might need more space for it than, say, one page, the Documentation team propose a new Handbook under DevHub.
The slug for this Handbook depends on the name we settle with. Also, it would be a good time to decide if we want to have this Handbook built and generated from GitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ (like WP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/, REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/., Block Editor and Coding Standards are) or do we want to publish content directly from WordPress.
Please leave your feedback in comments below by 25th February. Thank you.
#fse, #site-editor
