This example will incorporate the following examples from the existing repo

• https://github.com/WordPress/gutenberg-examples/tree/trunk/blocks-non-jsx/02-stylesheets
• https://github.com/WordPress/gutenberg-examples/tree/trunk/blocks-jsx/01-basic-esnext
• https://github.com/WordPress/gutenberg-examples/tree/trunk/blocks-jsx/01-basic-esnext
• https://github.com/WordPress/gutenberg-examples/tree/trunk/blocks-non-jsx/01-basic

This should a multi-block plugin containing all the JSX gutenberg-examples referenced in the tutorial:

I would just migrate the JSX examples and would skip for now the NON-JSX examples

• 01-basic-esnext → #31
• 02-stylesheets → there's no JSX example for this part but I think we should recreate 02-stylesheets in JSX version
• 03-editable-esnext → #33
• 04-controls-esnext → #34
• 05-recipe-card-esnext → #35
• 06-inner-blocks-esnext → #36
• 08-block-supports-esnext → #38
• 10-dynamic-block → #40

├── blocks-jsx
│   ├── 01-basic-esnext
│   ├── 03-editable-esnext
│   ├── 04-controls-esnext
│   ├── 05-recipe-card-esnext
│   ├── 06-inner-blocks-esnext
│   ├── 08-block-supports-esnext
│   ├── 10-dynamic-block
│   └── meta-block

composer run lint is returning some errors and provoking the main workflow to fail

I'm removing "*.php": [ "composer run lint"], from lint-staged until this issue is solved

⬢  block-development-examples  trunk ⦾ composer run lint
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar:///usr/local/bin/composer/vendor/symfony/console/Command/DumpCompletionCommand.php:48
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar:///usr/local/bin/composer/vendor/symfony/console/Command/DumpCompletionCommand.php:56
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:875
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:880
> ./vendor/bin/phpcs --standard=phpcs.xml
sh: ./vendor/bin/phpcs: No such file or directory
Script ./vendor/bin/phpcs --standard=phpcs.xml handling the lint event returned with error code 127

There's a package available in the repo that may be confusing for newcomers of this repo

https://github.com/WordPress/block-development-examples/pkgs/container/block-development-examples%2Fphp-actions_composer_block-development-examples

Could we remove it?

• Better order of columns of the table
  • ID - brief description - tags - zip - live view
• Get rid of color column
• Move that table to the very top
• Why this ID? Explain this in a WIKI page
  • Question mark - link to the WIKI page
• Include build folder in the repo for didactical purposes
  • Update getting started steps

Migrate from 05-recipe-card-esnext

I followed along the example of the Format API and but I was dumbfounded because I couldn't figure out how the icon was being imported and needed to import different one.

Action item:
Explicitly mention how the icon is being imported in the tutorial (or if the approach that I did more common, maybe include that )

Other buttons in the format bar were calling it in by importing WordPress' Icons package but that's not called in the format-api-f14b86 example.

I eventually figured out to import an existing WordPress icon by:

1. installing the Icons package (npm install @wordpress/icons --save),
2. in my js file, importing the package and then specifically importing the icon that i wanted to use import { commentReplyLink } from "@wordpress/icons"; List of icons is available at the storybook
3. within my RichTextToolbarButton component, adding the icon as an object like icon={commentReplyLink} unlike the example which in format-api-f14b86 which brings in a text string.

(for anyone else finding this: if you wanted to import your own, you probably could do it through through https://wordpress.github.io/gutenberg/?path=/docs/components-icon--docs

Relatedly, the richtexttoolbarbutton component (which appears to be a wrapper or abstraction?) is could have its documentation improved by although that should go in the gutenberg repository; since all that exists is the example in the rich-text readme and a separate reference in https://github.com/WordPress/gutenberg/tree/1eb76440f7b86ca905ac875d4a2c6ed67fc48daf/packages/block-editor which says it's undocumented.

It would be great to be able to tag an example as experimental. For example, the Interactivity API

Migrate 06-inner-blocks-esnext

Here are a few situations that examples would be useful for:

• A plugin containing multiple blocks (showing file structure / build configuration etc.)
• A custom data store
• A plugin containing multiple blocks utilizing the custom data store (particularly the build configuration is important here I think so that the data store doesn't get compiled into each block separately)

Based on the work done in the spreadsheet, these are the items in the existing Gutenberg Examples repo that need to be migrated over.

• #31 @ryanwelcher
• #32 @ryanwelcher
• #33 -- @juanmaguitar
• #34 @juanmaguitar
• #35 @juanmaguitar
• #36 @ryanwelcher
• #37 @ryanwelcher
• #38 @ryanwelcher
• #39 -- @juanmaguitar
• #40 @ryanwelcher
• #19 @ryanwelcher
• #20 @juanmaguitar
• #18 @ryanwelcher

We need to add some E2E tests to ensure that blocks are inserted and displayed correctly.

This should be done only for examples that are not tagged as NON-BLOCK

For my work on #38, I thought I was working on a branch and instead pushed to trunk directly. This is bad. Can we protect the branch so we can't update trunk unless it's from a PR? I don't have access to do it myself.

The diagram mentioned in Conventions for examples still references the old name "Gutenberg Examples". It would be nice to get this updated, but not sure how to access the original file. Would you be able to update this @juanmaguitar?

What?

We need to update each plugin to explain the learning goal/objective, provide details on the code, and link to any relevant references as needed.

• basic-block-translations-3df23d
• basic-esnext-a2ab62
• block-dynamic-rendering-64756b
• block-static-rendering-b16608
• block-supports-6aa4dd
• controls-a9cfe0
• data-basics-59c8f8
• dynamic-block-b0bce7
• editable-block-1b8c51
• format-api-f14b86
• inner-blocks-dcd824
• interactive-blocks-demos-99def1
• interactivity-api-block-833d15
• meta-block-bb1e55
• minimal-block-ca6eda
• minimal-block-no-build-e621a6
• non-block-react-wp-data-56d6f3
• plugin-sidebar-9ee4a6
• recipe-card-744e8a
• slotfill-2fb190
• stylesheets-79a4c3

ReadMe Example to follow

Basic Block Translation 3df23d

The goal of this example is to showcase how to use translations in a block.

Folder	Short description	Tags	ID (❓)	Download .zip	Live Demo
📁	Basic Block with Translations	STATIC RENDERING	3df23d	📦

Understanding the Example Code

Both the edit.js and save.js files import the __ function @wordpress/i18n to apply translations to the texts used in the code.

• The __ function receives the text and a namespace as parameters
• At index.php we tell WordPress our JavaScript contains translations, using the wp_set_script_translations() function.
• At languages/ folder there are all the translations files (the source files and the .mo ones actually used to apply the translations)

Related resources

• Internationalization
• __()
• wp_set_script_translations()

Note
Check the Start Guide for local development with the examples

To support https://make.wordpress.org/core/2021/12/28/take-more-control-over-inner-block-areas-as-a-block-developer/

I cloned the repo and followed the Quick start guide to install and build.

I then ran pnpm -- wp-env start and received the following error:

Success: WordPress installed successfully.
Success: Added the constant 'FS_METHOD' to the 'wp-config.php' file with the value 'direct'.
Success: Updated the constant 'WP_DEBUG' in the 'wp-config.php' file with the raw value 'false'.
Success: Added the constant 'SCRIPT_DEBUG' to the 'wp-config.php' file with the raw value 'false'.
Success: Added the constant 'WP_ENVIRONMENT_TYPE' to the 'wp-config.php' file with the value 'local'.
Success: Added the constant 'WP_PHP_BINARY' to the 'wp-config.php' file with the value 'php'.
Success: Added the constant 'WP_TESTS_EMAIL' to the 'wp-config.php' file with the value '[email protected]'.
Success: Added the constant 'WP_TESTS_TITLE' to the 'wp-config.php' file with the value 'Test Blog'.
Success: Added the constant 'WP_TESTS_DOMAIN' to the 'wp-config.php' file with the value 'localhost:8889'.
Success: Added the constant 'WP_SITEURL' to the 'wp-config.php' file with the value 'http://localhost:8889'.
Success: Added the constant 'WP_HOME' to the 'wp-config.php' file with the value 'http://localhost:8889'.
Success: Added the constant 'JETPACK_AUTOLOAD_DEV' to the 'wp-config.php' file with the raw value 'true'.
Success: Added the constant 'WP_DEBUG_LOG' to the 'wp-config.php' file with the raw value 'true'.
Success: Added the constant 'WP_DEBUG_DISPLAY' to the 'wp-config.php' file with the raw value 'true'.
Plugin 'block-dynamic-rendering-64756b' activated.
Success: Activated 1 of 1 plugins.
 Container d07e259cdf8f3f7e35b966a1a019160c-tests-mysql-1  Running
 Container d07e259cdf8f3f7e35b966a1a019160c-tests-wordpress-1  Running
Warning: The 'basic-block-3df23d' plugin could not be found.
Error: No plugins activated.

This is due to the .wp-env.json having a references to folders that don't exist in the plugins entry

Create a new example (or examples) to provide live demos of the snippets of code provided at
https://developer.wordpress.org/block-editor/reference-guides/block-api/block-transforms/

Migrate from 08-block-supports-esnext

Now that 6.5 is out, we can probably remove the experimental tag from examples that use the IAPI.

The existing scaffolding tools work very well for copying from existing plugins. We should add a create-block template to allow starting a new plugin from scratch.

Explanation: Requires Gutenberg

Plugin requires header

✅ How to use the header

Todo

• Find how to require a plugin in the header

Requires Plugins: gutenberg

• Include the Gutenberg plugin as a requirement if necessary for these blocks
• Update plugin header for Interactivity API Countdown
• Update plugin headers documentation in the Plugin Handbook

Background

The Interactivity API won't work without the Gutenberg Plugin active. There's a new header that will throw an error in the dashboard for this (as of 6.5). Trying to get word on this header so it can be documented.

How was it discovered?

The Playground demo worked, so the code wasn't broken.

raw blueprint file

{
        "step": "installPlugin",
        "pluginZipFile": {
          "resource": "wordpress.org/plugins",
          "slug": "gutenberg"
        }

Error track

from console

Uncaught TypeError: Cannot read properties of undefined (reading 'startCountdown')
    at interactivity.min.js?ver=6.5:2:25942
    at Array.forEach (<anonymous>)
    at interactivity.min.js?ver=6.5:2:25927
    at interactivity.min.js?ver=6.5:2:25951
    at interactivity.min.js?ver=6.5:2:29636
    at Object.__ (interactivity.min.js?ver=6.5:2:27702)
    at vt (interactivity.min.js?ver=6.5:2:13563)
    at Array.forEach (<anonymous>)
    at at (interactivity.min.js?ver=6.5:2:12275)

Steps to reproduce

• Clone the repo
• Move blocks from /plugins to /wp-content/plugins in your installation
• Install packages
• Run build
• Insert interactive countdown block
• No countdown

Possible culprits

• 👋 Gutenberg not installed?
• 🚫 interactivity API dependencies in package-lock.json?
• 🚫 viewScript changes?
• ⁇ No data from datastore?

Migrate from 04-controls-esnext

Migrate the existing example and update to JSX

in entry-meta "improve it on github" text does not link to github.
<p class="external-link"><a href="">Improve it on GitHub<span class="screen-reader-text">: Tutorial: Build your first block</span></a></p>

Migrate from 09-code-data-basics-esnext

Create a new or migrate the existing example from the current examples repo

Migrate from 10-dynamic-block

(so "npm i" works outside this repo for each example)

Update plugin-sidebar-9ee4a6 to recreate with JSX the example explained in Block Editor Handbook - How-to Guides- Plugin Sidebar
Once is published, update the Block Editor Handbook - How-to Guides- Plugin Sidebar to match the code snippets with the code of this example

Migrate the existing example to this repo. It will most likely need to be restructured.

I have found the 06 Conventions for examples a bit challenging to read/parse, and I think it could be improved with some additional formatting and more context. I found myself struggling to follow it when trying to add a new block to the repo.

@juanmaguitar I am happy to take this on but I wanted to flag it before I did so.

As per this: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-context/#example

See #58 for the example to follow.

Migrate current example

create a folder” – I am not sure I understand the purpose - I did not do this step and the tutorial worked okay.
"Therefore, create a new directory (folder) on your computer called “Block Tutorial”

“line 9” — this is relative, after a few file edits, the code referenced was not on line 9 for me
"So open up the file and add the following section after the example in line 9."

Migrate from 07-slotfills-esnext

To complement this documentation page https://developer.wordpress.org/block-editor/reference-guides/packages/packages-dataviews/

Description

In order to take a look at blocks in this repo, there are a couple of steps needed:

• Clone the repo
• Move all files from the repo's /plugins folder to wp-content/plugins for your local installation
• Build the NPM packages for each block (takes running/installing multiple times)

Proposal

Is there a way to save @wordpress/scripts in the wp-content/plugins directory, and build this one time?

Otherwise, if you had a local copy of wp-scripts at a source folder, let's say
~/users/username/dev/wp-scripts

To access all builds from one wp-scripts package?

Caveats

I realize you can do this by bootstrapping multiple plugins, but I'm thinking of never having to re-install the wp-scripts package again... just update it for one copy on your machine.

Also realize there can be some dependency issues here, and also some issues with needing extra packages such as useDebounce ..

Migrate from 03-editable-esnext

Migrate from 02-stylesheets

• Improve WP Playground by showing the block inserted with some text
• Also improve the description of the example
• Maybe show the content of wp_postmeta in the post
• Add Step 3: Use post meta data

I went through the process of creating a new example by running npm run create-example and for the most part it was a easy and straightforward process.

The only feedback I would give is that the step of choosing the tags was a little confusing for me. This is mostly because I didn't fully read the instructions and pressed enter to select a tag which confirmed my choices 🤦 . I would say that perhaps we need to have the tags in alphabetical order as they seemed random to me during my second try.

This is great tool for copying existing plugins in the repo and this coupled with a create-block template cover all of options for creating new examples.

The plugin Basic Block Translation 3df23d (basic-block-translations-3df23d) not translated.

I've extract this plugin folder from downloaded file > add to WordPress plugins folder > activated > changed settings to Espanol language.

Go to Appearance > widgets in WordPress admin dashboard.

Added Example: Basic block.

It's showing Hello World!!. instead of Hola Mundo!!

I'm following this document and try with this plugin but translation seems to be not working at all.

Having the info creation-date, last-updated and author for each example will help with contributions and will make the examples more useful (as more context about them will be provided)

A simple WordPress block plugin that utilizes both a render.php file and a save.js file. On the front end, the render.php file takes precedence, but if the plugin is ever disabled, the save.js file serves as a fallback, so a copyright date is still displayed.

https://github.com/ndiego/copyright-date-block

I'd like to make sure we have the correct tools in place in the repo to ensure that all code that is submitted follows the WordPress coding standards. We already have eslint/prettier available from @wordpress/scripts but I propose we add PHP Code Sniffer with WPCS 3.0 as well. We can then leverage Husky to check the code before it's committed and also add an Action to run the linting tools

Migrate the existing example from the current repo

The Data Basic example (https://github.com/WordPress/block-development-examples/tree/trunk/plugins/data-basics-59c8f8) has a number of links at the bottom of the README under "Related resources".

Several of these are broken:
https://developer.wordpress.org/block-editor/reference-guide/packages/packages-_data/
https://developer.wordpress.org/block-editor/reference-guide/packages/packages-_data/#useselect
https://developer.wordpress.org/news/2023/05/useentityrecords-an-easier-way-to-fetch-wordpress-_data/

It'd be nice with an example (no build) that would add a simple button to this "editor toolbar", to more or less mimic the possibilities we had to add a TinyMCE button. I think there are a lot of plugins that do just that, to access short codes, insert macros, or whatever.

If you haven't worked with this level of JS before, I think many "PHP developers" are left out in the cold, so to speak, because of the steep learning curve introduced with block elements.