Add a "Live Preview" link for theme reviewers

[adamziel]

Adds a "Live preview" link to the automated trac ticket comment that gets posted when a new theme version is submitted for a review. See an example of the automated comment.

The link leads to a WordPress Playground instance set up with:

• The version of the theme listed in the comment
• Imported theme unit test data
• The Theme Check plugin installed and activated
• WP_DEBUG enabled

Caveats

Zip URL

The zip file URL used in the comment follows this pattern:

https://wordpress.org/themes/download/gutenify-shoppe.1.0.0.zip?nostats=1

However, I used the following URL for this PR:

https://downloads.wordpress.org/theme/gutenify-shoppe.1.0.0.zip?nostats=1

Why?

1. The former URL redirects to the latter, even for themes that are not live yet
2. Playground uses fetch() and can only interact with URLs that provide appropriate Access-Control-* headers. Only the latter URL does that.

Missing images in the theme unit test data

The theme unit test data references images from a wordpress.com site that doesn't provide the Access-Control-* headers and thus can't be downloaded. A fix would involve updating the following XML file to load images from raw.githubusercontent.com: https://raw.githubusercontent.com/WordPress/theme-test-data/master/themeunittestdata.wordpress.xml

This is outside of scope for this PR and can be addressed separately if needed.

Testing instructions

I am not sure how to test this PR 😆 Any suggestions @dd32 @acosmin?

Implementation

The following Blueprint is used to achieve this setup (preview in the Blueprints builder):

{
  "preferredVersions": {
    "php": "7.4",
    "wp": "latest"
  },
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "defineWpConfigConsts",
      "consts": {
        "WP_DEBUG": true
      }
    },
    {
      "step": "importFile",
      "file": {
        "resource": "url",
        "url": "https://raw.githubusercontent.com/WordPress/theme-test-data/master/themeunittestdata.wordpress.xml",
        "caption": "Downloading theme testing content"
      },
      "progress": {
        "caption": "Installing theme testing content"
      }
    },
    {
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org/plugins",
        "slug": "theme-check"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "installTheme",
      "themeZipFile": {
        "resource": "url",
        "url": "https://downloads.wordpress.org/theme/pendant.1.0.15.zip",
        "caption": "Downloading the theme"
      }
    }
  ]
}

Trac ticket: https://meta.trac.wordpress.org/ticket/7382

[dd32]

I am not sure how to test this PR 😆

Testing the Trac integrations is never easy :) because of that I don't usually actually test it.. I just do it live 🤠

The part that can be tested though is the PHP in a standalone file, and a Trac admin can edit the existing trac tickets/comments with the new generated text to see how it works.

Unfortunately, the link in the PR as-is is a bit.. finicky with Trac.. the Trac linking code gets a bit confused by the { and [ in the link.

The zip file URL used in the comment follows this pattern:

https://wordpress.org/themes/download/...

Ha.. there's no reason that specific link format was used here, other than legacy reasons, it pre-dates downloads.wordpress.org being a "thing", so I'll change that as part of this.

Missing images in the theme unit test data
This is outside of scope for this PR and can be addressed separately if needed.

Agreed, this is a change that should be made, but it doesn't need to be done before this is implemented.

I'm not 100% sure on the blueprint, the PR used one which doesn't import the test data, so I've used the one from the description, which seems to work.

I'm also not 100% sure that hard-coding the blueprint into the Trac tickets is the right way to go, we might be better off having a redirect location like https://wordpress.org/themes/wp-json/trt/live-preview?slug={$slug}&version={$version}, but I guess in a way it's good that it's hard-coded, it means that future PHP version changes in the blueprint won't change the url in older tickets, etc.. so I'm just going to hard-code it for now.