10up / block-catalog Goto Github PK

More info: #10

Describe the bug

There a few PHP Warnings in the plugin when running on PHP 8.2.

Deprecated: Optional parameter $sites declared before required parameter $opts is implicitly treated as a required parameter in /chroot/var/www/wp-content/plugins/block-catalog/includes/classes/CatalogCommand.php on line 410 

Deprecated: Optional parameter $args declared before required parameter $opts is implicitly treated as a required parameter in /chroot/var/www/wp-content/plugins/block-catalog/includes/classes/CatalogCommand.php on line 431

Steps to Reproduce

1. With the Block Catalog Plugin active, on a PHP 8.2 environment.
2. Run any WP CLI command like, wp --help.
3. You will see a few PHP warnings that originate in the Block Catalog plugin.

Screenshots, screen recording, code snippet

No response

Environment information

• PHP 8.2+

WordPress information

• Any

Code of Conduct

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

This issue is for tracking changes for the 1.5.2 release. Target release date: November 2023.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.5.2 for your changes.
• Version bump: Bump the version number in block-catalog.php, package-lock.json, package.json, and readme.txt if it does not already reflect the version being released. In block-catalog.php update both the plugin "Version:" property and the plugin BLOCK_CATALOG_PLUGIN_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 .gitattributes.
• 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.
• 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.5.1 do not make it into the release, update their milestone to 1.6.0 or Future Release.

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

More info: #10

This issue is for tracking changes for the 1.5.4 release. Target release date: February 2024.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.5.4 for your changes.
• Version bump: Bump the version number in block-catalog.php, package-lock.json, package.json, and readme.txt if it does not already reflect the version being released. In block-catalog.php update both the plugin "Version:" property and the plugin BLOCK_CATALOG_PLUGIN_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 .gitattributes.
• 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.
• 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.5.4 do not make it into the release, update their milestone to 1.6.0 or Future Release.

More info: #10

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.

Describe the bug

Oddly, when viewing the catalog page (e.g. wp-admin/edit.php?block-catalog=core-preformatted) that contain a particular block, when that block is used as an inner block, that page is not listed in the GUI.

However, when using the wp block-catalog find command, posts containing blocks that are used as inner blocks are returned in the results.

I am able to reproduce in both instances when the posts have published status or draft status.

Steps to Reproduce

1. create a new post or page, ideally on a fresh, plain site with minimal content.
2. add a inner block to the post content.
   In the code example below, there's a preformatted block within a group block; and it's the only use of the preformatted block on this site.

<!-- wp:group {"layout":{"type":"flex","flexWrap":"nowrap"}} -->

<div class="wp-block-group"><!-- wp:paragraph -->
<p>this is an example of within a group block</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">this is preformatted text within a group block</pre>
<!-- /wp:preformatted --></div>
<!-- /wp:group -->

3. publish
4. Index posts
5. view block catalog (wp-admin/edit-tags.php?taxonomy=block-catalog). You'll see that the block, when used, as an inner block, is included in the count of how many times that block appears on the site.
6. visit the catalog page for a particular block (wp-admin/edit.php?block-catalog=core-preformatted); you'll see that no pages or posts are listed as containing that block.
7. wp block-catalog find core/preformatted ; you'll find that the post/page is correctly listed containing the preformatted block

Screenshots, screen recording, code snippet

Environment information

n/a

WordPress information

gutenberg 15.8.1, WP 6.2.1

Code of Conduct

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

Describe your question

Describe your question

This issue is for tracking changes for the 1.6.1 release. Target release date: July 2024.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.6.1 for your changes.
• Version bump: Bump the version number in block-catalog.php, package-lock.json, package.json, and readme.txt if it does not already reflect the version being released. In block-catalog.php update both the plugin "Version:" property and the plugin BLOCK_CATALOG_PLUGIN_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 .gitattributes.
• 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.
• 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.6.1 do not make it into the release, update their milestone to 1.7.0 or Future Release.

Code of Conduct

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

Describe the bug

I am running my site on PHP 8.2 with WP_DEBUG set to true. The error logs at the top of the screen flag the use of variables in strings.

Deprecated: Using ${var} in strings is deprecated, use {$var} instead in /var/www/html/wp-content/plugins/block-catalog/includes/core.php on line 166

Deprecated: Using ${var} in strings is deprecated, use {$var} instead in /var/www/html/wp-content/plugins/block-catalog/includes/core.php on line 184

Steps to Reproduce

1. Update to PHP 8.2
2. enabled WP_DEBUG
3. Activate this plugin
4. View the frontend

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

WordPress 6.2.2

Code of Conduct

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

More info: #10

Is your enhancement related to a problem? Please describe.

Is some kind of dashboard planned for a future release where a content editor can view all instances where a specific block is used, rather than relying on the post type/taxonomy screen?

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

Objective:

This GitHub issue will serve as a task to prepare Critical Flow (also known as Test Cases) for this repository/plugin.

• Guide for Creating Critical Flow of 10up OSS Projects.

Please comment on this issue if you don't have:

• Access to edit Wiki Pages
• The repository does not have Wiki Page enabled

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.5
Upcoming version: 6.6

This issue will be closed automatically when the versions match.

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

Release steps

• Branch: Starting from develop, cut a release branch named release/1.5.1 for your changes.
• Version bump: Bump the version number in block-catalog.php, package-lock.json, package.json, and readme.txt if it does not already reflect the version being released. In block-catalog.php update both the plugin "Version:" property and the plugin BLOCK_CATALOG_PLUGIN_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 .gitattributes.
• 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.
• 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.5.1 do not make it into the release, update their milestone to 1.5.2, 1.6.0 or Future Release.

Describe your question

This issue is for tracking changes for the 1.6.0 release. Target release date: May 2024.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.6.0 for your changes.
• Version bump: Bump the version number in block-catalog.php, package-lock.json, package.json, and readme.txt if it does not already reflect the version being released. In block-catalog.php update both the plugin "Version:" property and the plugin BLOCK_CATALOG_PLUGIN_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 .gitattributes.
• 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.
• 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.6.0 do not make it into the release, update their milestone to 1.7.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.

The current main PHP file is named plugin.php whereas our OSS standard is to usually match the project name, in this case could/should be block-catalog.php. So this issue documents the need to update the filename and any other references within the codebase.

Designs

n/a

Describe alternatives you've considered

n/a

Code of Conduct

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

This issue is for tracking changes for the 1.5.2 release. Target release date: November 2023.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.5.3 for your changes.
• Version bump: Bump the version number in block-catalog.php, package-lock.json, package.json, and readme.txt if it does not already reflect the version being released. In block-catalog.php update both the plugin "Version:" property and the plugin BLOCK_CATALOG_PLUGIN_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 .gitattributes.
• 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.
• 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.5.3 do not make it into the release, update their milestone to 1.6.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.4
Latest version: 6.5

This issue will be closed automatically when the versions match.