Merge pull request #765 from publishpress/release-v2.11.2

Release v2.11.2

.builder-post-rsync-filters-post

@@ -0,0 +1,21 @@
+- composer.json
+- composer.lock
+- vendor/publishpress/vendor-locator/composer.json
+- vendor/publishpress/vendor-locator/composer.json
+- vendor/publishpress/wordpress-banners/.gitattributes
+- vendor/woocommerce/action-scheduler/README.md
+- vendor/woocommerce/action-scheduler/changelog.txt
+- vendor/publishpress/wordpress-version-notices/.gitignore
+- vendor/publishpress/wordpress-version-notices/README.md
+- vendor/publishpress/wordpress-version-notices/bin
+- vendor/publishpress/wordpress-version-notices/codeception.dist.yml
+- vendor/publishpress/wordpress-version-notices/codeception.yml
+- vendor/publishpress/wordpress-version-notices/tests
+- vendor/bin
+- vendor/publishpress/vendor-locator-series/composer.json
+- vendor/sabre/vobject/.gitignore
+- vendor/sabre/vobject/bin
+- vendor/sabre/vobject/composer.json
+- vendor/sabre/vobject/README.md
+- vendor/sabre/vobject/tests
+- vendor/symfony/polyfill-ctype/README.md

.builder-rsync-filters

@@ -1,10 +1,8 @@
 - *.code-workspace
 - .babelrc
+- .builder-post-rsync-filters-post
 - .builder-rsync-filters
 - .distignore
-- .env.testing.linux.dist
-- .env.testing.mac.dist
-- .eslintrc.js
 - .git
 - .gitattributes
 - .github
@@ -16,46 +14,28 @@
 - .phplint.yml
 - .vscode
 - .wordpress-org
-- /dist
 - Gruntfile.js
 - README-build.md
 - README.md
 - RoboFile.php
+- assets/jsx
 - bin
 - builder
 - builder.yml
-- builder.yml.dist
 - codeception.dist.yml
-- cypress
-- cypress.json
-- jest.config.ts
+- cs
+- /dev-workspace
+- /dist
 - jsconfig.json
-- mix-manifest.json
 - node_modules
 - package-lock.json
 - package.json
-- phpcs.xml
 - psalm.xml
 - ray-dist.php
 - ray.php
 - screenshot-*.png
-- scripts
-- tailwind.config.js
 - tests
-- vendor/publishpress/wordpress-reviews/phpcs.xml.dist
-- vendor/publishpress/wordpress-version-notices/.gitignore
-- vendor/publishpress/wordpress-version-notices/README.md
-- vendor/publishpress/wordpress-version-notices/bin
-- vendor/publishpress/wordpress-version-notices/codeception.dist.yml
-- vendor/publishpress/wordpress-version-notices/codeception.yml
-- vendor/publishpress/wordpress-version-notices/tests
-- webpack.config.js
-- webpack.mix.js
-- .env.testing
-- .env.testing.dist
-- CONTRIBUTING.md
-- assets_wp
-- phpunit.xml
-- vendor/bin
-- vendor/symfony/polyfill-ctype/composer.json
-- vendor/bin
+- vendor
+- /version.txt
+- /webpack.config.js
+- /yarn.lock

.gitattributes

@@ -0,0 +1,16 @@
+.github export-ignore
+assets_wp export-ignore
+tests export-ignore
+.babelrc export-ignore
+.env.testing.dist export-ignore
+.gitignore export-ignore
+.phplint.yml export-ignore
+codeception.dist.yml export-ignore
+composer.json export-ignore
+composer.lock export-ignore
+package.json export-ignore
+package-lock.json export-ignore
+RoboFile.php export-ignore
+webpack.config.js export-ignore
+.gitattributes export-ignore
+.git export-ignore

.github/ISSUE_TEMPLATE/release-free-plugin.md

@@ -4,34 +4,31 @@ about: Describes default checklist for the plugin's release process.
 title: Release v[VERSION]
 labels: release
 assignees: ''
-
 ---
 
 To release the Free plugin please make sure to check all the checkboxes below.
 
 ### Pre-release Checklist
-
-- [ ] Create the release branch as `release-<version>` based on the development branch
-- [ ] Make sure to directly merge or use Pull Requests to merge hotfixes or features branches into the release branch
-- [ ] Run `composer update` and check if there is any relevant update. Check if you need to lock the current version for any dependency. The `--no-dev` argument is optional here, since the build script will make sure to run the build with that argument.
-- [ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct
-- [ ] Update the version number to the next stable version. Use `$ vendor/bin/robo version <version-number>`
-- [ ] Commit the changes to the release branch
-- [ ] Build the zip package using `$ vendor/bin/robo build`. It should create a package in the `./dist` dir.
-- [ ] Send to the team for testing
+- [ ] Create the release branch as `release-<version>` based on the development branch.
+- [ ] Make sure to directly merge or use Pull Requests to merge hotfixes or features branches into the release branch.
+- [ ] Run `composer update --no-dev --dry-run` and check if there is any relevant update on any requirement. This won't change the code, just show a simulation of running the update command. Evaluate the need of releasing with this library updated, or if we can add that for a next release.
+- [ ] If any update should be included on this release (from previous step) make sure to run the update command only for the specific dependeny: `composer update the/lib:version-constraint`. Make sure to check compatibility with the plugin and what version we should be using. Check if you need to lock the current version for any dependency using exact version numbers instead of relative version constraints. Make sure to add any change of dependencies to the changelog.
+- [ ] Check Github's Dependabot warnings or pull requests, looking for any relevant report. Remove any false-positive first. Fix and commit the fix for the issues you find.
+- [ ] Build JS files to production running `composer build:js` and commit (if your plugin uses any compiled JS file).
+- [ ] Run WP VIP scan to make sure no warnings or errors > 5 exists: `composer phpcs`.
+- [ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct.
+- [ ] Update the version number to the next stable version in the main plugin file and `readme.txt`. Commit the changes to the release branch.
+- [ ] Commit the changes to the release branch.
+- [ ] Build the zip package, running `composer build`. It should create a package in the `./dist` dir.
+- [ ] Send the new package to the team for testing.
 
 ### Release Checklist
+- [ ] Create a Pull Request and merge the release branch it into the `master` branch.
+- [ ] Merge the `master` branch into the `development` branch.
+- [ ] Create the GitHub release (make sure it is based on the `master` branch and correct tag). This will trigger a Github action for automatic deployment on the WordPress SVN repo.
 
-- [ ] Create a Pull Request and merge the release branch it into the `master` branch
-- [ ] Merge the `master` branch into the `development` branch
-- [ ] Create the Github release (make sure it is based on the `master` branch and correct tag)
+### Post-release Checklist
 
-#### SVN Repo
-- [ ] Cleanup the `trunk` directory.
-- [ ] Unzip the built package and move files to the `trunk`
-- [ ] Remove any eventual file that shouldn't be released in the package (if you find anything, make sure to create an issue to fix the build script)
-- [ ] Look for new files `$ svn status | grep \?` and add them using `$ svn add <each_file_path>`
-- [ ] Look for removed files `$ svn status | grep !` and remove them `$ svn rm <each_file_path>`
-- [ ] Create the new tag `$ svn cp trunk tags/<version>`
-- [ ] Commit the changes `$ svn ci -m 'Releasing <version>'`
-- [ ] Wait until WordPress updates the version number and make the final test updating the plugin in a staging site
+- [ ] Follow the action's result on the [repository actions page](https://github.com/publishpress/publishpress-series/actions).
+- [ ] Go to the [WordPress.org plugin page](https://wordpress.org/plugins/organize-series/) double check the information confirming the release finished successfully.
+- [ ] Make a final test updating the plugin in a staging site.

.github/ISSUE_TEMPLATE/release-pro-plugin.md

@@ -4,27 +4,36 @@ about: Describes default checklist for releasing the Pro plugin;
 title: Release Pro v[VERSION]
 labels: release
 assignees: ''
-
 ---
 
 To release the Pro plugin please make sure to check all the checkboxes below.
 
 ### Pre-release Checklist
 
-- [ ] Create the release branch as `release-<version>` based on the development branch
-- [ ] Make sure to directly merge or use Pull Requests to merge hotfixes or features branches into the release branch
-- [ ] Clone free version shared file to pro version
-- [ ] Run `composer update` and check if there is any relevant update. Check if you need to lock the current version for any dependency. The `--no-dev` argument is optional here, since the build script will make sure to run the build with that argument.
-- [ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct
-- [ ] Update the version number to the next stable version. Use `$ vendor/bin/robo version <version-number>`
-- [ ] Commit the changes to the release branch
-- [ ] Build the zip package using `$ vendor/bin/robo build`. It should create a package in the `./dist` dir.
-- [ ] Send to the team for testing
+- [ ] Create the release branch as `release-<version>` based on the development branch.
+- [ ] Make sure to directly merge or use Pull Requests to merge hotfixes or features branches into the release branch.
+- [ ] Run `composer update --no-dev --dry-run` and check if there is any relevant update on any requirement. This won't change the code, just show a simulation of running the update command. Evaluate the need of releasing with this library updated, or if we can add that for a next release.
+- [ ] If any update should be included on this release (from previous step) make sure to run the update command only for the specific dependeny: `composer update the/lib:version-constraint`. Make sure to check compatibility with the plugin and what version we should be using. Check if you need to lock the current version for any dependency using exact version numbers instead of relative version constraints. Make sure to add any change of dependencies to the changelog.
+- [ ] Check Github's Dependabot warnings or pull requests, looking for any relevant report. Remove any false-positive first. Fix and commit the fix for the issues you find.
+- [ ] Build JS files to production running `composer build:js` and commit (if your plugin uses any compiled JS file).
+- [ ] Run WP VIP scan to make sure no warnings or errors > 5 exists: `composer phpcs`.
+- [ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct.
+- [ ] Update the version number to the next stable version in the main plugin file and `readme.txt`. Commit the changes to the release branch.
+- [ ] Commit the changes to the release branch.
+- [ ] Build the zip package, running `composer build`. It should create a package in the `./dist` dir.
+- [ ] Send the new package to the team for testing.
 
 ### Release Checklist
 
-- [ ] Create a Pull Request and merge the release branch it into the `master` branch
-- [ ] Merge the `master` branch into the `development` branch
-- [ ] Create the Github release (make sure it is based on the `master` branch and correct tag)
-- [ ] Update EDD registry and upload the new package
-- [ ] Make the final test updating the plugin in a staging site
+- [ ] Create a Pull Request and merge the release branch it into the `master` branch.
+- [ ] Merge the `master` branch into the `development` branch.
+- [ ] Create the Github release (make sure it is based on the `master` branch and correct tag).
+- [ ] Follow the action's result on the [repository actions page](https://github.com/publishpress/publishpress-series-pro/actions).
+- [ ] Go to [PublishPress site admin panel](https://publishpress.com/wp-admin) > Downloads, locate "Series Pro", and edit:
+  - [ ] File URL on Download Files, uploading the new package to the media library.
+  - [ ] On Licensing, update the version number.
+  - [ ] On Licensing, update the changelog.
+
+### Post-release Checklist
+
+- [ ] Make the final test updating the plugin in a staging site.

.gitignore

@@ -25,9 +25,7 @@ node_modules
 
 /.properties.ini
 
-/vendor
-.idea
 /dist
 .env.testing
 builder.yml
-phpcs.xml
+phpcs.xml

addons/grouping/legacy-includes.php

@@ -207,10 +207,10 @@ function orgseries_grouping_taxonomy() {
     $permalink_slug = 'series_group';
     $object_type = array('series_grouping');
     $capabilities = array(
-        'manage_terms' => 'manage_series',
-        'edit_terms' => 'manage_series',
-        'delete_terms' => 'manage_series',
-        'assign_terms' => 'manage_series'
+        'manage_terms' => 'manage_publishpress_series',
+        'edit_terms' => 'manage_publishpress_series',
+        'delete_terms' => 'manage_publishpress_series',
+        'assign_terms' => 'manage_publishpress_series'
     );
     $labels = array(
         'name' => _x('Series Categories', 'taxonomy general name', 'organize-series'),
@@ -272,7 +272,7 @@ function orgseries_grouping_import_existing_series() {
 }
 
 function orgseries_groups_admin_menu() {
-    add_submenu_page( 'edit.php', 'Series Categories', 'Series Categories', 'manage_series', 'edit-tags.php?taxonomy=series_group');
+    add_submenu_page( 'edit.php', 'Series Categories', 'Series Categories', 'manage_publishpress_series', 'edit-tags.php?taxonomy=series_group');
 }
 
 function orgseries_group_add_queryvars($qvs) {