Streamline content updates, by automating PRs for content updates

[dd32]

Currently the process for updating an existing page is to..

• Update the page in the Page Editor
• Checkout this repo
• Run build & pattern build
• Commit changes, PR, Merge
• Sync & Deploy wordpress.org

This PR reduces the process and removes the requirement for the merger to have a local working environment.

With this change the flow is:

• Update the page in the Page Editor
• Run the Workflow (We can automate this, to happen after a page edit, or on a cron schedule)
• Review & Merge the PR
• Sync & Deploy wordpress.org

There's a very slight change in the process there, but notably it doesn't require a local environment for basic text-only updates.

This could be improved by..

• Including screenshot of modified pages
• Verifying no fatal errors are present in the modified files

For an example of the generated PR, see https://github.com/dd32/wporg-main-2022/pull/1

As this flow is becoming more used, this could be made as a generic action imported from https://github.com/wordpress/wporg-repo-tools/ once confirmed working and acceptable.

Edit: Just noting that this includes a fix for the upstream mariadb+wp-env issue; this can be removed before merge, we'll need to separately update the wp-env package or wait for the upstream mariadb docker image to update, before this will work without it.

[dd32]

Perhaps the most important change here, is that it'd create a ticket queue of "Hey, there's been a content update by someone, review and deploy" without needing to have the editor contact a meta developer to sync.

[ryelle]

I really like this idea, but I think we need to tweak some things in the parser before auto-applying the synced changes. When I sync patterns, I usually end up manually adjusting the changeset slightly before committing.

For example, looking at https://github.com/dd32/wporg-main-2022/pull/1/files

• The ref attributes are added to menus, but then ignored(?) because the menus are displayed using menuSlug — I believe that will still work as expected, but it would be nicer if we could remove the useless ref
• This thing ❦ probably doesn't need to be translated
• The embed block's content should also not be translated, it breaks the spacing so the embed isn't embedded anymore (unless that's been fixed in the last 6ish months)

[dd32]

@ryelle I totally agree, I was surprised to see some of these changes included, but if the parser needs to be updated to ignore some content, we should do that, to avoid needing us to pick and choose which changes.

[dd32]

I've pushed two changes to the parsers:

• Don't translate core/embed
• Don't translate <p> strings less than 2 characters.

The example PR now reflects that, so here's what was initially included:	core/embed	paragraph

These were the two parser related changes noted above, the ref items are still there in the wp:navigation blocks, I suspect that would need to be removed from the API that exposes these blocks rather than being done within this block parser? But we can probably add another transformation specifically for <!-- wp:navigation .+ --> to remove attributes as needed.

[dd32]

I expect iteration will be required on the PR content, but merging for now to finalise testing.

[dd32]

I've setup a task on WordPress.org/ to initiate a run of this workflow 5 minutes after a page edit occurs.

That's in /mu-plugins/main-network/site-main.php r21715-dotorg.

Why 5 minutes? There needed to be some kind of rate limiting, this seemed short enough.

Example run: https://github.com/WordPress/wporg-main-2022/actions/runs/8015893967