Describe your question

This issue is for tracking changes for the 1.0.2 release. 🎉 Target release date: 27 June 2022

Release steps

• Branch: Starting from develop, cut a release branch named release/1.0.2 for your changes.
• Version bump: Bump the version number in insecure-content-warning.php, readme.txt, and package.json if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin INSECURE_CONTENT_VERSION constant in insecure-content-warning.php.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt
• Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Push: Push your trunk branch to GitHub, e.g. git push origin trunk.
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/insecure-content-warning/milestone/4?closed=1).
• SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/insecure-content-warning/. This may take a few minutes.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.0.2 milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 1.0.2 do not make it into the release, update their milestone to 1.1.0 or Future Release.

Is your enhancement related to a problem? Please describe.

We only look at post_content so the featured image is never considered. This would be a new feature to add.

Additional links
Link to the thread can be found here.

There is a new WordPress version that the plugin hasn't been tested with. Please test it and then change the "Tested up to" field in the plugin readme.

Tested up to: 6.0
Latest version: 6.1

This issue will be closed automatically when the versions match.

For @adamsilverstein

I get this when I try to npm run build:

/Users/tlovett1/.nvm/versions/node/v6.7.0/lib/node_modules/webpack/bin/convert-argv.js:492 throw new Error("'output.filename' is required, either in config file or as --output-filename");

Describe the bug

When saving a page which have a Classic Block on it containing insecure elements, the plugin doesn't find them and saves the post without a warning.

Steps to Reproduce

1. Create new post with Classic Editor, add insecure elements
2. Save the post with insecure elements
3. Insecure Warning is shown
4. Click "Publish with insecure assets" and publish the post
5. Open the post in Block Editor
6. The content is in single "Classic" Block
7. Save the post
8. The post is saved without Insecure warning

Expected to see Insecure Warning when saving the post with insecure elements inside Classic Block

Screenshots, screen recording, code snippet

Environment information

No response

WordPress information

Code of Conduct

• I agree to follow this project's Code of Conduct

• Readme final review
• Tag and release
• Open gitub repository

@helen do you want to do a code review/test this out before release? can you help set up the repo with all the default settings/.mds we want before making it public?

The warning messages really belong in the pre-publish panel where the user is reviewing information about the post before publishing it:

A new API was recently introduced in Gutenberg that adds a slot in the pre-publish panel we can leverage:

WordPress/gutenberg#6798

Here is a code sample from the PR that uses the slot: https://gist.github.com/gziolo/fd8141f2cde7fcb1b513c09eea45d27f (you can paste this into your browser!)

This issue is for tracking changes for the 1.0.0 release. 🎉 Target release date: TBD June 2021

Release steps

• Branch: Starting from develop, cut a release branch named release/1.0.0 for your changes.
• Version bump: Bump the version number in insecure-content-warning.php, readme.txt, and package.json if it does not already reflect the version being released. In insecure-content-warning.php update both the plugin "Version:" property and the plugin INSECURE_CONTENT_VERSION constant.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt
• Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Push: Push your trunk branch to GitHub, e.g. git push origin trunk.
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/insecure-content-warning/milestone/1?closed=1).
• SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/insecure-content-warning/. This may take a few minutes.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.0.0 milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 1.0.0 do not make it into the release, update their milestone to 1.1.0 or Future Release.

Post-release steps

• update the commit hash placeholder in the 1.0.0 link in CHANGELOG.md

Is your enhancement related to a problem? Please describe.

Cypress 13 was recently released, and Cypress 12 contains some breaking changes as listed below. We need to update our tests to make them work with the latest version and fix any issues that may arise.

• Upgrade cypress to 13.0.0 (or latest version at the time of working on this)
• Upgrade @10up/cypress-wp-utils to 0.2.0
• Replace legacy API usage such as Cookies.defaults with the new replacements.

Breaking changes we need to be aware of

• Cypress dropped support for Node.js 12
• In Cypress 12, we enforce running tests in a clean browser context through test isolation.
• The Cookies.defaults and Cookies.preserveOnce APIs have been removed. Use the new cy.session() command to preserve cookies between tests.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.
In #39 a WP-CLI script was added to scan for insecure items and attempt to fix those. This is a nice approach to bulk fix content for sites that may have been converted from insecure to secure but still have references to insecure items.

Not all users will have the access or capability to run a WP-CLI command though, so would be great to add an option in the admin to run the same functionality.

Describe the solution you'd like
Have a place somewhere in the admin where you can initiate a scan for insecure items. Might want some options like the content type to scan and the number of items to scan at a time and maybe an autofix option. This would then run the scan and let you know the items that it finds (and if autofix is on, if the items were able to be fixed).

I can see a similar approach to what is done in ElasticPress, if we want to use that as a reference.

It'd be a nice UX touch to visually highlight to the assets that are flagged as insecure. Ideally, this would add a border to assets in the visual editor, and highlight the asset text in the text editor.

https://cl.ly/0Y1x1C3i271L

Bump WP & PHP Minimums to the following

• WordPress to 5.7
• PHP to 7.4
• Remove any no-longer-needed conditional code for older version support.
• Take a look at adjusting our testing matrices, if applicable.
• Bump the minimums in plugin documentation and header fields.

Is your enhancement related to a problem? Please describe.

See overall concept in the OSBP guide and example setups on Simple Podcasting, Restricted Site Access, and 10up/ElasticPress#2446.

Describe the solution you'd like

add base GitHub Action
add .wp-env.json
add base docker files
update package.json / package lock files
add cypress tests
remove any WP Acceptance components

Designs

n/a

Describe alternatives you've considered

n/a

Additional context

https://github.com/10up/cypress-wp-setup/ && https://github.com/10up/cypress-wp-utils will be helpful in getting this spun up and some initial test commands to leverage.

• Add "Build release zip" GitHub Action to generate the release zip before the actual release.
• Release Instructions are updated to test generated zip before shipping the release.

Reference PR: 10up/autoshare-for-twitter#201

The pluralized element/elements strings are constructed in an English-centric way; other languages may have different grammatical structures and the concatenation order won't work for them. In PHP this would be _n() and _nx() - I am not sure what the Jed/Gutenberg equivalent is.

I think it will be useful if we can check if the image can use HTTPS and auto replace it (maybe settings to disable/enable this).

There is a new WordPress version that the plugin hasn't been tested with. Please test it and then change the "Tested up to" field in the plugin readme.

Tested up to: 6.2
Latest version: 6.3

This issue will be closed automatically when the versions match.

Is your enhancement related to a problem? Please describe.

This is to align with the current tooling versions used by WordPress - https://make.wordpress.org/core/2023/12/20/updating-wordpress-to-use-more-modern-versions-of-node-js-npm-2/

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe the bug

I tested 'insecure-content-warning' plugin version -1.0.0 with WP version 5 8.3 and WP version 5.9 and I found that on WP 5.9 version 'Fix' functionality of the plugin is not working and when user clicks on "FIX" button then nothing happens and user is not able to publish a page or post.
In WP 5.8.3 insecure content URL is getting fix when user clicks on 'FIX' button. User can publish post or page and 'HTTPS' is appearing in a link of insecure content instead of 'HTTP' after fixing content.

Steps to Reproduce

1. Install Plugin.
2. Add page or post.
3. Add media through insecure URL. Ex: http://www.goodmorningimagesdownload.com/wp-content/uploads/2019/12/Love-Images-4.jpg
4. Try to publish page or post.
5. You will see insecure content error.
6. Try to fix the content.
7. Notice issue.

Screenshots, screen recording, code snippet

Uploading Recording #34.mp4…

Environment information

Windows 11
Chrome version - 97.0.4692.71

WordPress information

WP version 5.9 RC1
Insecure content warning plugin version - 1.0.0

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

@10up/eslint-config couldn't be updated as it couldn't satisfy the node and NPM requirements.

Adding to it, after upgrading node to 16, stylelint fails during installation.

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.
Once WordPress 5.9 is released, we'll want to test Insecure Content Warning to see if any incompatibility issues arise.

Describe the solution you'd like

• test Insecure Content Warning on WordPress 5.9
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
n/a

Additional context
Related: #48.

Script would iteratively scan posts for insecure assets and replace when possible. Would produce report of fixed/ not fixed

This issue is for tracking changes for the 1.2.0 release. Target release date: October 2023

Release steps

• Branch: Starting from develop, cut a release branch named release/1.2.0 for your changes.
• Version bump: Bump the version number in insecure-content-warning.php, readme.txt, package.json and package-lock.json if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin INSECURE_CONTENT_VERSION constant in insecure-content-warning.php.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt
• Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk, ensuring you pull the most recent changes into develop first (git checkout develop && git pull origin develop && git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Push: Push your trunk branch to GitHub, e.g. git push origin trunk.
• Compare trunk to develop to ensure no additional changes were missed.
• Test the pre-release ZIP locally by downloading it from the Build release zip action artifact and installing it locally. Ensure this zip has all the files we expect, that it installs and activates correctly and that all basic functionality is working.
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/insecure-content-warning/milestone/7?closed=1).
• SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• Check WordPress.org: Ensure that the changes are live on WordPress.org. This may take a few minutes.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 1.2.0 do not make it into the release, update their milestone to 1.2.1, 1.3.0 or Future Release.

we probably want to think about how we ensure it gets seen, if it happens before a page reload.

Is your enhancement related to a problem? Please describe.
Once WordPress 5.8 is released, we'll want to test Insecure Content Warning to see if any incompatibility issues arise.

Describe the solution you'd like

• test Insecure Content Warning on WordPress 5.8
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
n/a

Additional context
Related: n/a.

There is a new WordPress version that the plugin hasn't been tested with. Please test it and then change the "Tested up to" field in the plugin readme.

Tested up to: 6.1
Latest version: 6.2

This issue will be closed automatically when the versions match.

This issue is for tracking changes for the 1.1.0 release. Target release date: June 2023

Release steps

• Branch: Starting from develop, cut a release branch named release/1.1.0 for your changes.
• Version bump: Bump the version number in insecure-content-warning.php, readme.txt, package.json and package-lock.json if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin INSECURE_CONTENT_VERSION constant in insecure-content-warning.php.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt
• Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk, ensuring you pull the most recent changes into develop first (git checkout develop && git pull origin develop && git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Push: Push your trunk branch to GitHub, e.g. git push origin trunk.
• Compare trunk to develop to ensure no additional changes were missed.
• Test the pre-release ZIP locally by downloading it from the Build release zip action artifact and installing it locally. Ensure this zip has all the files we expect, that it installs and activates correctly and that all basic functionality is working.
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/insecure-content-warning/milestone/6?closed=1).
• SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• Check WordPress.org: Ensure that the changes are live on WordPress.org. This may take a few minutes.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 1.1.0 do not make it into the release, update their milestone to 1.2.0 or Future Release.

There is a new WordPress version that the plugin hasn't been tested with. Please test it and then change the "Tested up to" field in the plugin readme.

Tested up to: 6.3
Latest version: 6.4

This issue will be closed automatically when the versions match.

See WordPress/gutenberg#10649 - we can now directly control whether the user can publish/update a post.

wp.data.dispatch( 'core/editor' ).lockPostSaving( 'mylock' );

wp.data.dispatch( 'core/editor' ).unlockPostSaving( 'mylock' );

Is your enhancement related to a problem? Please describe.

All the E2E tests for WP minimum are failing.

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe the bug
Testing on a fresh install of WordPress (v5.5.1), this plugin doesn't work at all in Gutenberg. I imagine it's probably not been working in Gutenberg for awhile.

From what I'm seeing, there are two main issues here:

1. The Gutenberg related JS is only loaded if a certain constant is set, yet this constant is never set in this plugin (it's a constant that comes from the Distributor plugin). So without the Distributor plugin active, the Gutenberg code will never even load
2. Even with that fixed, this plugin uses the Notices API quite a bit and that API has changed significantly since this was originally written, so it doesn't work

Steps to Reproduce

1. Install the plugin on WordPress 5.5
2. Create a new post using Gutenberg
3. Add an insecure image to the content
4. Try publishing the post

Expected behavior
Insecure assets should be flagged when using Gutenberg, the same as if using the Classic Editor

There is an upcoming WordPress version in the release candidate stage that the plugin hasn't been tested with. Please test it and then change the "Tested up to" field in the plugin readme.

Tested up to: 6.4
Upcoming version: 6.5

This issue will be closed automatically when the versions match.

Is your enhancement related to a problem? Please describe.

There are few NPM scripts that call composer even though there are no composer.json or composer-lock.json files present. We can clean these up.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

We are currently running E2E tests by installing dependencies and building plugin files. This is not the most accurate plugin build that will be shipped during the release. To make E2E tests more accurate and match the plugin build with the release build generated by our deploy action, we should generate a plugin build with the "build zip" action. Running E2E tests on this build will give us more accurate results.

PR for reference: 10up/autoshare-for-twitter#206

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe the bug

When having a post with multiple different insecure content instances, when the button to fix the first one is fixed every attempt to fix one of the other instances fails. Same for the highlighting.

Steps to Reproduce

1. Create a post with this content

<!-- wp:image {"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img src="http://cdn.pixabay.com/photo/2015/06/19/21/24/avenue-815297_960_720.jpg" alt=""/></figure>
<!-- /wp:image -->

<!-- wp:image {"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img src="https://cdn.pixabay.com/photo/2016/09/07/16/19/pile-1651945_1280.jpg" alt=""/></figure>
<!-- /wp:image -->

<!-- wp:image {"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img src="https://cdn.pixabay.com/photo/2014/08/15/11/29/beach-418742_1280.jpg" alt=""/></figure>
<!-- /wp:image -->

<!-- wp:paragraph -->
<p>aaa</p>
<!-- /wp:paragraph -->

2. Try to save the post
3. Click the button to fix the first one, it gets fixed without issues.
4. Click the button to fix the second and the third one. Each attempt should fail to fix the content without any visible errors

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your question

This issue is for tracking changes for the 1.0.3 release. 🎉 Target release date: 09 January 2023

Release steps

• Branch: Starting from develop, cut a release branch named release/1.0.3 for your changes.
• Version bump: Bump the version number in insecure-content-warning.php, readme.txt, package.json and package-lock.json if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin INSECURE_CONTENT_VERSION constant in insecure-content-warning.php.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt
• Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Add zip release tool here and update release instructions
• Push: Push your trunk branch to GitHub, e.g. git push origin trunk.
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/insecure-content-warning/milestone/5?closed=1).
• SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/insecure-content-warning/. This may take a few minutes.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.0.3 milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 1.0.3 do not make it into the release, update their milestone to 1.1.0 or Future Release.

I think a plugin like this should probably be 5.3+ and needs a plugin header to match. I noticed at least one usage of [] array shorthand, which is 5.4+. Opening this issue to ensure a review before release.

Is your enhancement related to a problem? Please describe.
We currently listen for direct clicks on the publish button to know when to run our checks. This means the shortcut will never fire anything from us. We would either need to add this or refactor our save listener to be more inline with how Gutenberg works (like listening for isSavingPost)

Additional links

Link to the thread can be found here.

Describe your question

This issue is for tracking changes for the 1.0.1 release. 🎉 Target release date: 17 February 2022

Release steps

• Branch: Starting from develop, cut a release branch named release/1.0.1 for your changes.
• Version bump: Bump the version number in insecure-content-warning.php, readme.txt, and package.json if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin INSECURE_CONTENT_VERSION constant in insecure-content-warning.php.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt
• Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Push: Push your trunk branch to GitHub, e.g. git push origin trunk.
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/insecure-content-warning/milestone/2?closed=1).
• SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/insecure-content-warning/. This may take a few minutes.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.0.1 milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 1.0.1 do not make it into the release, update their milestone to 1.1.0 or Future Release.

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

Once WordPress 6.0 is released, we'll want to test Insecure Content Warning to see if any incompatibility issues arise.

Describe the solution you'd like

• test Insecure Content Warning on WordPress 6.0
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
n/a

Additional context
Related: #62, #48

If you preview with the insecure elements warning showing, the preview opens and seems to work correctly but the preview and publish/update button are left disabled. However, clicking on the update button actually still runs the content scanner and updates the error messages.

I suppose you should still be able to preview with the warnings showing, just whatever is happening that doesn't re-enable the buttons should be fixed. And perhaps ensure that the event triggering the scanner doesn't include the button in its disabled state.

Is your enhancement related to a problem? Please describe.
In #39, a WP-CLI script was added to bulk scan and fix issues. But this script isn't mentioned anywhere in our documentation, either here or on WordPress.org.

Describe the solution you'd like
Documentation should be added on this script and how to use it. Probably also worth highlighting that this is an option in the main plugin description.

More info: 10up/convert-to-blocks#123 (comment)