Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 1.3.0 #44

Merged
merged 37 commits into from
Jul 16, 2020
Merged

Version 1.3.0 #44

merged 37 commits into from
Jul 16, 2020

Conversation

stevegrunwell
Copy link
Contributor

Added

Updated

Fixed

stevegrunwell and others added 30 commits May 19, 2020 04:52
I used our example code as a basis when responding to https://wordpress.org/support/topic/limit-per-minute/, and noticed two issues in our example code:

1. A leftover reference to "fortnightly" (from an earlier version of that sample code)
2. Comparing the custom interval against the string "interval", not the variable `$interval`, when calculating the start of the next interval. This was resulting in the next interval being the same as the current.
This commit adds the following headers to the main plugin file, per https://developer.wordpress.org/plugins/plugin-basics/header-requirements/#header-fields:

* Requires at least
* Requires PHP
* License
* License URI

Fixes #30.
Fix example code for defining custom intervals
This commit introduces a new workflow, using [10up's WordPress.org Plugin Readme/Assets Update GitHub action](https://github.com/10up/action-wordpress-plugin-asset-update).

When changes to the readme.txt file and/or anything in `.wordpress-org/` gets pushed on the `master` branch, these assets will automatically be sent to WordPress.org. This makes it easier to, for example, bump the "Tested up to" values without requiring a whole new release
Push readme and/or asset changes to WordPress.org automatically
…in OrderLimiterTest::count_qualifying_orders_should_not_limit_results()

Instead of using the WP default of 10 and generating 24 orders (which takes some time), lower the default setting to 2, then generate 5 orders.

Locally, this has sped up test suite execution by ~10s.
…laced within the current interval, as changing the settings will cause those to be recalculated
The plugin headers declare WordPress 5.3 as the minimum supported version, yet the "Minimum requirements" Travis CI job was using WordPress 5.2.

The reason we use 5.3 is for [the date/time improvements](https://make.wordpress.org/core/2019/09/23/date-time-improvements-wp-5-3/), as well as the fact that 5.2 is old (current WP release branch is 5.4.x); there's no sense in polyfilling this functionality as store owners *should* be running the latest version of WordPress.
There have been a few requests in the WordPress.org forums for examples of custom interval plugins, which I've written as GitHub gists. Considering these may be useful to others, this PR adds those gists' links to the README file.
Use WordPress 5.3 in the "Minimum Requirements" CI job
…gs-change

Automatically clear transient upon settings change
This commit registers a new tool within the WooCommerce > Status > Tools page that lets store administrators clear the order limiter transient.

Additionally, clearing all WooCommerce order transients (via `wc_delete_shop_order_transients()`, which is called as part of the "WooCommerce transients" tool), will clear our limiter transient as well.

Fixes #35.
Register a "Reset Order Limiting" WooCommerce tool
Add new filters to the OrderLimiter
WooCommerce 4.3 was released last week, so this commit bumps the "WC tested up to" value in the plugin header to match.

Naturally, this also puts 4.3 into the (explicit) Travis testing matrix.
@stevegrunwell stevegrunwell added the release Preparing for a release label Jul 16, 2020
@stevegrunwell stevegrunwell added this to the Version 1.3.0 milestone Jul 16, 2020
@stevegrunwell stevegrunwell changed the base branch from develop to master July 16, 2020 14:42
stevegrunwell and others added 3 commits July 16, 2020 15:05
The latter method wasn't introduced until PHPUnit 7.5, which means we'd either need to polyfill the method for PHPUnit 6.x (required for PHP 7.0) *or* just use `assertContains()` until we're able to drop PHP 7.0.
Use assertContains() instead of assertStringContainsString()
Bump the "WC tested up to" to version 4.3
limit-orders.php Outdated Show resolved Hide resolved
@stevegrunwell stevegrunwell marked this pull request as ready for review July 16, 2020 15:28
@stevegrunwell stevegrunwell requested a review from bswatson July 16, 2020 15:29
@bswatson bswatson merged commit 63d5cde into master Jul 16, 2020
@bswatson bswatson deleted the release/v1.3.0 branch July 16, 2020 15:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release Preparing for a release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants