Playground Preview button in plugin directory doesn't always work if you have Release Confirmation active

[dartiss]

This is referring to the implementation of the Playround preview button in ticket #7251

I've found that, when Release Confirmation is active for a plugin, if you push a blueprint file to the assets folder (which doesn't require confirmation), it doesn't always work. By then making a change that requires confrmation, the blueprint is then accepted and the button works.

But it's hit-and-miss.

Let me give an example. I added valid blueprint files to the assets folders for World Domination(​https://wordpress.org/plugins/world-domination/) and Pride Bar (​https://wordpress.org/plugins/pride-bar/). Both plugins have Release Confirmation active.

The latter worked and the Preview button appeared. The former didn't. It wasn't until I pushed a code change out and needed to confirm it that the preview button started working.

I spoke to Alex Shiels (@tellyworth) about this in Slack (​https://wordpress.slack.com/archives/C04EWKGDJ0K/p1713163486921979)and it was is suggestion that it was Release Management, despite it sometimes working, despite me having it active on all my plugins.

[dd32]

The way that Release confirmations work is that it aborts the plugin parsing early, for safety. So the way it's currently working is "per design" although it's not ideal at all and deserves changing.

Assets being parsed as part of the plugin release process is kind of a vestige of all plugin assets belonging within a plugins tagged releases, rather than being part of /assets/.

It would be ideal to split the asset parsing out from the plugin parsing, and always run the asset parse. That would allow for blueprints to be imported, screenshots/banner updates, and potentially we could also look at running readme.txt updates as part of that.

[dd32]

See also; #6419 (Same thing - just readme.txt changes instead of blueprint)

[dd32]

Upon looking at this, it's slightly different than I originally suspected. This is still release-confirmation related, but not how I thought it was.

At the time, the plugin world-domination was in an "invalid state".

Release Confirmation was enabled, but no release had yet been made. As a result, the parsing of the plugin on the blueprint step aborted because...
[world-domination] Plugin Import Failed: Plugin cannot be released from trunk due to release confirmation being enabled.

Specifically, trunk/readme.txt had Stable Tag: 1.0.1 (yet tags/1.0.1 didn't exist, so it defaulted to trunk) ​https://plugins.trac.wordpress.org/browser/world-domination/trunk/readme.txt?rev=3055665&marks=8

Once a plugin release was made, the plugin was in an expected state, and the asset parsing worked as expected.

As far as I can tell, had the plugin have had a tags/1.0.1 folder at the time of Release Confirmation being enabled, this issue would not have occurred.

[dartiss]

Thanks for the investigation @dd32.

Whilst I appreciate the cause, it's in no way obvious that this is the problem or why something like would affect the blueprint from working. Is there any way of getting the blueprint to still work in this situation or, alternatively, a way to flag the cause?

[dd32]

Replying to dartiss:

Whilst I appreciate the cause, it's in no way obvious that this is the problem or why something like would affect the blueprint from working.

If anything, this needs to be resolved in the opt-in to Release Confirmation instead.