Implement plugin with Gutenberg block types for Update PHP page

[flixos90]

The Update PHP information page (which is currently live at ​https://wordpress.org/support/upgrade-php/) requires a bit of dynamic content that should be implemented as custom Gutenberg block types.

We need a plugin that contains those block types, plus additional functionality the page might need. Let's use the slug update-php for the plugin. The following steps are needed for the first iteration:

• Scaffold the plugin, including typical Webpack and Babel workflows for plugins extending Gutenberg. Support for Sass should be built-in as well.
• Implement a block type update-php/version-notice that uses server-side rendering (similar like core/latest-posts for example). The block type should check a URL query parameter php_version, and if provided act on it. The content that should conditionally be displayed would depend on whether the version is supported or out of date. However, all text for the different conditions should be specified via block type controls. See the beginning of the ​https://docs.google.com/document/d/1_L76gu0Uj-7qNKazpuKyIn1TwnNk8kE20-anMVOgyHg/edit for what content should be hosted and for an idea of what the basic markup should look like. The actual texts would only be provided via the block controls (as they are connected to the page content) and should not have any defaults, as that would require redundant translations later when the page is localized.
• Request design help to provide styling to the block which fits with wordpress.org/support/ appearance. The Sass needed can accompany the block type.
• Implement a simple piece of logic to redirect from {$homeurl}/upgrade-php/ to {$homeurl}/update-php/. Right before the plugin is activated later, the existing page's slug should be modified from "upgrade-php" to "update-php".

Since this process consists of multiple steps, it's fine iterating over them. A first patch would be great to only provide the block type logic and not bother adding design. However, the markup generated should preferably support content somewhat similar to the Google doc linked above.

Further block types for the Update PHP page will likely be required, but those haven't been determined yet and could also be implemented in follow-up tickets. Let's set the first milestone to the things that we already know we need (mentioned above) and commit once they are ready.

[nerrad]

Okay the initial build of the plugin is done.

The repository is for the plugin here: ​https://github.com/nerrad/update-php
A release build (for installation from zip) is here: ​https://github.com/nerrad/update-php/archive/0.1.0.zip

Regarding redirect logic requested:

Implement a simple piece of logic to redirect from {$homeurl}/upgrade-php/ to {$homeurl}/update-php/. Right before the plugin is activated later, the existing page's slug should be modified from "upgrade-php" to "update-php".

I don't think this should be done by the plugin but instead should be something done at the server level. Having plugins handle redirects of this nature is more resource intensive (because WordPress has to be loaded twice) than simply adding the redirect to the webserver config. So maybe request this from the wp.org systems team?

Flow

Here's some gifs showing the block in action (editor and frontend) Note: The links below work when clicking on them (trac isn't embedding it as content though).

Creating the block and toggling what is previewed in the editor:

Modifying content:

Frontend:

Summary

• The plugin is built so that adding additional blocks we need should be fairly straightforward. I did not add sass yet because imo that's overkill at the moment. Currently only simple CSS should be needed.
• From the doc linked to (​https://docs.google.com/document/d/1_L76gu0Uj-7qNKazpuKyIn1TwnNk8kE20-anMVOgyHg/edit) it appeared that there are three distinct sections for the markup of the first block. So I followed that for the various content options in the block (title, body, and emphasis).
• I have not implemented any styling yet. The block itself is within a container with the class detected-php-content. The title is in a <h4> tag, the body is just a paragraph block, and the emphasis section is a paragraph block with the css class detected-php-emphasis so styling should be fairly straightforward. I can help with that or anyone can submit a pull request.

The block:

• Currently is added to the widgets category for blocks and just has a simple "list" icon. This can change.
• Allows for modification of the various sections of the markup (body, title, emphasis) for two states: outdated, up-to-date.
• Has immediate preview of changes in markup available in the editor (it is _not_ using <ServerSideRender> because the block is simple so quicker to do js preview. Also, no need for unnecessary round-trips to the server).
• Has a method of toggling between out-dated preview and up-to-date php version preview.
• Allows for setting what the minimum php version is used to consider for "up-to-date" messaging.

The frontend:

• looks for php_version in the request (that can easily be changed if something else is used) and displays the appropriate messaging from the block attributes. If there is no php_version in the request then none of the block content is shown.

What Next?

• Need css implemented for block (auto-prefixr is already configured for builds)
• There is currently no variation in css between the two content types (out-dated, up-to-date). I'm guessing we may want that and it can easily be added.
• What category should the block go in (or a new category?)
• What icon should be given the block?
• Review and tweak any default text if necessary.
• Add php and js automated tests (I held off doing this until I know whether this is a go as is or not).
• I'm not sure of the procedure for getting this on wp.org. I'm assuming it will require a patch to add the plugin to the meta repo.

[dd32]

I'm personally not convinced that a Gutenberg plugin is actually needed for this, as it seems like a perfect use-case for a page template and theme-specific CSS. Just because it can be used, doesn't mean it should be.

Is there any background available anywhere as to why this page has been done as a WordPress page, and not as a SVN revisioned document like every other page on WordPress.org?

[SergeyBiryukov]

Per the latest ​#core-php chat, closing in favor of #4004.