[wp-meta] [Making WordPress.org] #3789: Implement plugin with Gutenberg block types for Update PHP page

[Making WordPress.org]

#3789: Implement plugin with Gutenberg block types for Update PHP page
-------------------------+-------------------------
 Reporter:  flixos90     |      Owner:  nerrad
     Type:  task         |     Status:  assigned
 Priority:  normal       |  Milestone:
Component:  Support Hub  |   Keywords:  needs-patch
-------------------------+-------------------------
 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.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/3789>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org