-
Notifications
You must be signed in to change notification settings - Fork 2
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
Version 1.3.0 #44
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Add missing plugin headers
Fix example code for defining custom intervals
Verify WooCommerce 4.2 compatibility
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.
Add links to custom interval gists
Use WordPress 5.3 in the "Minimum Requirements" CI job
…gs-change Automatically clear transient upon settings change
…ders_pre_get_remaining_orders' filters
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.
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
bswatson
suggested changes
Jul 16, 2020
…e_shown_if_there_have_been_orders_in_the_current_interval
bswatson
approved these changes
Jul 16, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added
limit_orders_pre_count_qualifying_orders
andlimit_orders_pre_get_remaining_orders
— for customizing the logic around counting qualifying and remaining orders, respectively (Add new filters to the OrderLimiter #41)Updated
Fixed