Describe your question

This issue is for tracking changes for the 1.1.1 release. Target release date: May 2023.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.1.2 for your changes.
• Version bump: Bump the version number in ad-refresh-control.php, package.json, package-lock.json and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in both CHANGELOG.md and readme.txt.
• Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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/ad-refresh-control/milestone/10?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/ad-refresh-control/. 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.2 do not make it into the release, update their milestone to 1.2.0 or Future Release.

Code of Conduct

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

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

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 ad-refresh-control.php, package.json, and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
• Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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 latest stable release.
• Test: While still on the trunk branch, test for functionality locally.
• 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/Ad-Refresh-Control/milestone/8?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/ad-refresh-control/. This may take a few minutes.
• Close the 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 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.

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.

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 a Wiki Page enabled

This issue is for tracking changes for the 1.0.1 release. 🎉 Target release date: TBD September 2020.

Pre-release steps

• NEEDED: review #16, resolve any issue, and merge

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 ad-refresh-control.php, package.json, and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
• Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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 latest stable release.
• Test: While still on the trunk branch, test for functionality locally.
• 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](https://github.com/10up/Ad-Refresh-Control/milestone/3?closed=1).
• Version bump (again): In the develop branch (cd ../ && git checkout develop) bump the version number in ad-refresh-control.php, package.json, and readme.txt to X.Y.(Z+1)-dev. It's okay if the next release might be a different version number; that change can be handled right before release in the first step, as might also be the case with @since annotations.
• 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/ad-refresh-control/. This may take a few minutes.
• Close the 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.0.1 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.

Once WordPress 6.0 is released, we'll want to test Ad Refresh Control to see if any incompatibility issues arise.

• test Ad Refresh Control 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

none

Additional context
Related: #52, #32

Code of Conduct

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

This issue is for tracking changes for the 1.0.2 release. Target release date: TBD November 2020.

Pre-release steps

• NEEDED: review #22, resolve any issues, and merge.
• NEEDED: review #23, resolve any issues, and merge.
  - [ ] NEEDED: review #24, resolve any issues, and merge.

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 ad-refresh-control.php, package.json, and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
• Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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 latest stable release.
• Test: While still on the trunk branch, test for functionality locally.
• 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](https://github.com/10up/Ad-Refresh-Control/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/ad-refresh-control/. This may take a few minutes.
• Close the 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.0.2 do not make it into the release, update their milestone to 1.1.0, or Future Release.
• Version bump (again): In the develop branch (cd ../ && git checkout develop) bump the version number in ad-refresh-control.php, package.json, and readme.txt to 1.0.3-dev. It's okay if the next release might be a different version number; that change can be handled right before release in the first step, as might also be the case with @since annotations.

Is your enhancement related to a problem? Please describe.
Currently the plugin supports excluding based on advertiser ID, but there are instances where we may want to completely exclude a specific ad unit from refreshing instead of excluding all the possible advertiser IDs that can display in it.

Describe the solution you'd like
Backend:

• Add an additional field to the plugin's settings page that will accept a list of slot element IDs(strings). The slot element ID is the third argument passed to googletag.pubads().defineSlot(), which is the ID of the DIV that will contain the defined ad slot.
• Include the list of excluded slot element IDs within the wp_localize_script() call within includes/functions/core.php.

Frontend:

• We already obtain the slot element ID within the initializeSlotData() function. When the slot element ID is obtained there we can check it against the list of excluded slot element IDs passed into the window.AdRefreshControl object.

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.

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.

This issue is for tracking changes for the 1.1.1 release. Target release date: 19 December 2022.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.1.1 for your changes.
• Version bump: Bump the version number in ad-refresh-control.php, package.json, package-lock.json and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in both CHANGELOG.md and readme.txt.
• Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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/ad-refresh-control/milestone/9?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/ad-refresh-control/. 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.1 do not make it into the release, update their milestone to 1.1.2, 1.2.0 or Future Release.

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.2
Upcoming version: 6.3

This issue will be closed automatically when the versions match.

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

Describe the solution you'd like

• test Ad Refresh Control 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
none

Additional context
Related: #32.

This issue is for tracking changes for the 1.0.5 release. Target release date: June 2021.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.0.5 for your changes.
• Version bump: Bump the version number in ad-refresh-control.php, package.json, and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
• Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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 latest stable release.
• Test: While still on the trunk branch, test for functionality locally.
• 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/Ad-Refresh-Control/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/ad-refresh-control/. This may take a few minutes.
• Close the 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.0.5 do not make it into the release, update their milestone to 1.1.0 or Future Release.

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

Release steps

• Branch: Starting from develop, cut a release branch named release/1.1.3 for your changes.
• Version bump: Bump the version number in ad-refresh-control.php, package.json, package-lock.json and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in both CHANGELOG.md and readme.txt.
• Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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/ad-refresh-control/milestone/12?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/ad-refresh-control/. 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.3 do not make it into the release, update their milestone to 1.2.0 or Future Release.

I fixed one instance of this in #34 but it seems there's another call to initializeSlotData() that passes the slot rather than the whole event. As the slot is destructured from the event within initializeSlotData() it ends up as undefined and causes an error.

Describe the bug

The PHP coding standards workflow is currently failing due to a deprecation warning.

As a result merging of PRs is blocked.

Steps to Reproduce

See the error relating to PR #78, https://github.com/10up/Ad-Refresh-Control/actions/runs/3482820187/jobs/5825597122

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

This issue is for tracking changes for the 1.0.3 release. Target release date: 09 March 2021.

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 ad-refresh-control.php, package.json, and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
• Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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 latest stable release.
• Test: While still on the trunk branch, test for functionality locally.
• 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/Ad-Refresh-Control/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 https://wordpress.org/plugins/ad-refresh-control/. This may take a few minutes.
• Close the 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.0.3 do not make it into the release, update their milestone to 1.1.0 or Future Release.

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.3
Upcoming version: 6.4

This issue will be closed automatically when the versions match.

Is your enhancement related to a problem? Please describe.

The tooling is old and does not align with the modern setup.

Old packages prevent other packages from updating due to incompatible versions. See this.

Designs

No response

Describe alternatives you've considered

1. Remove unnecessary NPM deps.
2. Modernize tooling by using @wordpress/scripts.

Code of Conduct

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

Describe the bug

My GTMetrix performance report is reporting "Avoid serving legacy Javascript to modern browsers" for /dist/js/frontend.js, specifically for Array.prototype.includes (although this might be incorrectly reported).
Would it be possible to investigate?

Steps to Reproduce

More info here: https://gtmetrix.com/avoid-serving-legacy-javascript-to-modern-browsers.html

Screenshots, screen recording, code snippet

Environment information

No response

WordPress information

No response

Code of Conduct

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

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

Release steps

• Branch: Starting from develop, cut a release branch named release/1.1.4 for your changes.
• Version bump: Bump the version number in ad-refresh-control.php, package.json, package-lock.json and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in both CHANGELOG.md and readme.txt.
• Props: Update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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/ad-refresh-control/milestone/13?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/ad-refresh-control/. 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.4 do not make it into the release, update their milestone to 1.2.0 or Future Release.

This issue is for tracking changes for the 1.0.4 release. Target release date: 24 March 2021.

Release steps

• Branch: Starting from develop, cut a release branch named release/1.0.4 for your changes.
• Version bump: Bump the version number in ad-refresh-control.php, package.json, and readme.txt if it does not already reflect the version being released. In ad-refresh-control.php update both the plugin "Version:" property and the plugin AD_REFRESH_CONTROL_VERSION constant.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
• Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
• 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.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
• 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 latest stable release.
• Test: While still on the trunk branch, test for functionality locally.
• 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/Ad-Refresh-Control/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 https://wordpress.org/plugins/ad-refresh-control/. This may take a few minutes.
• Close the 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.0.4 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.
Once WordPress 5.7 is released, we'll want to test Ad Refresh Control to see if any incompatibility issues arise.

Describe the solution you'd like

• test Ad Refresh Control on WordPress 5.7
• 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
none

Additional context
none

Is your enhancement related to a problem? Please describe.

A new Action is released: https://github.com/10up/action-wordpress-plugin-build-zip/. This is already set up in a few PRs: Insert Special Characters, Autoshare for Twitter and Simple Podcasting. As an example, you can see/download the Simple Podcasting zip here.

Please go ahead and create the same in this repository.

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.
Received the following request via email:

We are looking to find a way to modify the setting ‘Refresh Interval’ on the ‘Ad Refresh Control’ plugin https://github.com/10up/Ad-Refresh-Control/. The specific line we want to modify is on the file https://github.com/10up/Ad-Refresh-Control/blob/develop/includes/settings.php line 249.

Ad-Refresh-Control/includes/settings.php

Line 249 in aef9926

if ( ! is_numeric( $settings['refresh_interval'] ) || intval( $settings['refresh_interval'] ) < 30 ) {

We need to be able to set a value of 20 - 25 on that interval refresh setting. Do you think that is something 10Up may consider doing on that plugin?

Describe the solution you'd like
In discussing with @davidrgreen there is concern "that we put a minimum of 30 seconds there because advertisers tend to view refreshes less than 30 seconds as too aggressive and it can end up ultimately hurting the publisher's relationship with the advertiser and thus revenue. Google for instance only allows down to 30 seconds as well, https://support.google.com/admanager/answer/6022114. If this is absolutely necessary, I would be more open to adding a filter in the code so that a developer can override the setting with the filter using code in order to use a lower value. That way at least a very conscious decision would have to be made to choose the lower value, and publishers who install the plugin cannot so easily choose a value less than 30 which would put them in a potentially dangerous spot."

So let's look at a filter here with specific recommendation in the docblock and readme that we strongly recommend not going below 30 seconds.

Designs

Describe alternatives you've considered

Additional context

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.

Describe the bug

The wp tenup-sitemaps generate CLI command produces a warning when the --range param is not included.

PHP Notice: Undefined index: range in /var/www/html/wp-content/plugins/10up-sitemaps/includes/classes/Command.php on line 55

Steps to Reproduce

Run wp tenup-sitemaps generate without the --range param. [Note: when a range is defined, there is no error.]

Screenshots, screen recording, code snippet

[10-Mar-2022 16:14:31 UTC] PHP Notice:  Undefined index: range in /var/www/html/wp-content/plugins/10up-sitemaps/includes/classes/Command.php on line 55
[10-Mar-2022 16:14:31 UTC] PHP Stack trace:
[10-Mar-2022 16:14:31 UTC] PHP   1. {main}() /usr/local/bin/wp:0
[10-Mar-2022 16:14:31 UTC] PHP   2. include() /usr/local/bin/wp:4
[10-Mar-2022 16:14:31 UTC] PHP   3. include() phar:///usr/local/bin/wp/php/boot-phar.php:11
[10-Mar-2022 16:14:31 UTC] PHP   4. WP_CLI\bootstrap() phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php:27
[10-Mar-2022 16:14:31 UTC] PHP   5. WP_CLI\Bootstrap\LaunchRunner->process($state = class WP_CLI\Bootstrap\BootstrapState { private $state = [] }) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php:77
[10-Mar-2022 16:14:31 UTC] PHP   6. WP_CLI\Runner->start() phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php:23
[10-Mar-2022 16:14:31 UTC] PHP   7. WP_CLI\Runner->run_command_and_exit($help_exit_warning = *uninitialized*) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php:1194
[10-Mar-2022 16:14:31 UTC] PHP   8. WP_CLI\Runner->run_command($args = [0 => 'tenup-sitemaps', 1 => 'generate'], $assoc_args = [], $options = *uninitialized*) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php:422
[10-Mar-2022 16:14:31 UTC] PHP   9. WP_CLI\Dispatcher\Subcommand->invoke($args = [], $assoc_args = [], $extra_args = []) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php:399
[10-Mar-2022 16:14:31 UTC] PHP  10. call_user_func:{phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:491}($function_name = class Closure { virtual $closure = "$this->WP_CLI\Dispatcher\{closure}", public $static = ['callable' => [...]]; public $parameter = ['$args' => '<required>', '$assoc_args' => '<required>'] }, ...$parameters = variadic([])) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:491
[10-Mar-2022 16:14:31 UTC] PHP  11. WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure:phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:97-104}($args = [], $assoc_args = []) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:491
[10-Mar-2022 16:14:31 UTC] PHP  12. call_user_func:{phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:100}($function_name = [0 => class TenupSitemaps\Command {  }, 1 => 'generate'], ...$parameters = variadic([])) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:100
[10-Mar-2022 16:14:31 UTC] PHP  13. TenupSitemaps\Command->generate($args = [], $assoc_args = []) phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:100

Environment information

MacOS running WP Local Docker V2.

WordPress information

The issue exists in 10up Sitemaps, however this was tested in both WP 5.8.3 and WP 5.9.1 and the same issue was logged in both versions.

Code of Conduct

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

• Remove languages files and makepot
• Remove any leftovers from initial scaffolding (unused tests, empty directories, etc.)
• Add GitHub Actions for deploy and readme/asset update

Describe the bug

When saving the plugin settings, I get the following PHP warnings. They all appear to be based on missing values. I believe the conditioning around these calls needs to be tightened to handle null values.

[03-Mar-2022 22:22:07 UTC] PHP Warning:  explode() expects parameter 2 to be string, array given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 297
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. explode() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:297
[03-Mar-2022 22:22:07 UTC] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 303
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. array_filter() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:303
[03-Mar-2022 22:22:07 UTC] PHP Warning:  array_map(): Expected parameter 2 to be an array, null given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 306
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. array_map() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:306
[03-Mar-2022 22:22:07 UTC] PHP Warning:  explode() expects parameter 2 to be string, array given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 321
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. explode() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:321
[03-Mar-2022 22:22:07 UTC] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 327
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. array_filter() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:327
[03-Mar-2022 22:22:07 UTC] PHP Warning:  array_map(): Expected parameter 2 to be an array, null given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 330
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. array_map() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:330
[03-Mar-2022 22:22:07 UTC] PHP Warning:  explode() expects parameter 2 to be string, array given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 354
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. explode() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:354
[03-Mar-2022 22:22:07 UTC] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 360
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. array_filter() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:360
[03-Mar-2022 22:22:07 UTC] PHP Warning:  array_map(): Expected parameter 2 to be an array, null given in /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 363
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. update_option() /var/www/html/wp-admin/options.php:322
[03-Mar-2022 22:22:07 UTC] PHP   3. add_option() /var/www/html/wp-includes/option.php:469
[03-Mar-2022 22:22:07 UTC] PHP   4. sanitize_option() /var/www/html/wp-includes/option.php:611
[03-Mar-2022 22:22:07 UTC] PHP   5. apply_filters() /var/www/html/wp-includes/formatting.php:4976
[03-Mar-2022 22:22:07 UTC] PHP   6. WP_Hook->apply_filters() /var/www/html/wp-includes/plugin.php:189
[03-Mar-2022 22:22:07 UTC] PHP   7. AdRefreshControl\Settings\sanitize_settings() /var/www/html/wp-includes/class-wp-hook.php:309
[03-Mar-2022 22:22:07 UTC] PHP   8. array_map() /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:363
[03-Mar-2022 22:22:07 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:303) in /var/www/html/wp-includes/pluggable.php on line 1355
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. wp_redirect() /var/www/html/wp-admin/options.php:349
[03-Mar-2022 22:22:07 UTC] PHP   3. header() /var/www/html/wp-includes/pluggable.php:1355
[03-Mar-2022 22:22:07 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/Ad-Refresh-Control/includes/settings.php:303) in /var/www/html/wp-includes/pluggable.php on line 1358
[03-Mar-2022 22:22:07 UTC] PHP Stack trace:
[03-Mar-2022 22:22:07 UTC] PHP   1. {main}() /var/www/html/wp-admin/options.php:0
[03-Mar-2022 22:22:07 UTC] PHP   2. wp_redirect() /var/www/html/wp-admin/options.php:349
[03-Mar-2022 22:22:07 UTC] PHP   3. header() /var/www/html/wp-includes/pluggable.php:1358

Steps to Reproduce

1. Install the Ad Refresh Control plugin on a vanilla WordPress install.
2. Enable WP_DEBUG
3. Go to the settings page at: /wp-admin/options-general.php?page=ad-refresh-control-settings
4. Scroll to the bottom of the page and click "Save Changes" without putting anything into the settings fields.
5. If WP_DEBUG is active, you should see the warnings.

Screenshots, screen recording, code snippet

No response

Environment information

• Device: Macbook Pro
• OS: OSX 12.2.1
• Browser shouldn't matter, but I'm on Chrome.

WordPress information

Using WordPress 5.9.1.

Code of Conduct

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

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

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.

Describe the bug

When saving settings on a new install of the plugin, fatal error occurs

Steps to Reproduce

1. Install plugin
2. Delete database entry in wp_options for option_name=avc_settings (to make sure this is a new install)
3. Open Ad Refresh Control settings page
4. Add a numeric value to "Excluded Advertiser IDs", "Line Items IDs to Exclude" or any value to "Slot IDs to Exclude"
5. Click "Save Changes"

Fatal error will occur in wp-content/plugins/Ad-Refresh-Control/includes/settings.php on line 297, 321 or 354, depending on which settings field was filled with data.

Screenshots, screen recording, code snippet

Environment information

No response

WordPress information

Code of Conduct

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

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.