This repository has been archived by the owner on Jun 15, 2022. It is now read-only.
Resolve WooCommerce test suite errors #31
Merged
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
…rce_orders table row, based on the order ID
…rieve the custom table name
…ast them as strings.
The WC_DateTime class explicitly defines a __toString() magic method, but according to the PHP documentation:
> Since PHP 5.2.0, it is called in any string context (e.g. in printf() with %s modifier) but not in other types contexts (e.g. with %d modifier).
Since WordPress' $wpdb->prepare() method isn't a true sprintf() replacement (as we saw with WordPress 4.8.*), the __toString() magic method isn't necessarily called, meaning we're attempting to shove a WC_DateTime instance into a "%s" placeholder and trying to stuff that into a DATETIME column in the table.
Without being cast to strings, the WooCommerce core test suite gets filled with warnings like this:
Unexpected incorrect usage notice for wpdb::prepare
Failed asserting that an array is empty.
…d the existing WC_Order_Data_Store_CPT class. This class already contains a lot of the funtionality we need, and it's much cleaner to extend the existing, core class with one that overrides only what we need to change.
…t was wholesale copied + pasted from the parent class
… 'created' property
… the parent class
…t suite. Additionally, fix a merge conflict that produced two 'autoload-dev' nodes.
…as been deprecated and isn't even being called
…queries with calls to the custom table, when available. If a column doesn't exist, WordPress should fall back to the meta queries
Methods that will be used as filter callbacks and never change based on the state of the object are really not appropriate as non-static methods, especially when we need to be able to hook and un-hook them from filter callbacks. For example, get_postmeta_mapping() will always return the same, hard-coded array, as nothing within the data store class was altering the (now-removed) $postmeta_mapping property. Having a static reference makes it much easier to add/remove actions and filters, since there's only a single instance to worry about.
…ustom order table is designed to replace the postmeta table, which stores values in VARCHAR(255). In order to preserve compatibility with WooCommerce queries, these values will need to be treated as strings for now.
…n has hard-coded queries against the postmeta table.
…e, the latter being cart_tax + shipping_tax, per WC_Abstract_Order::set_cart_tax()
…t as YYYY-MM-DD HH:MM:SS datetimes. To remain compatible, we should treat these database columns the same way until such point that we have tests and can reliably convert them to a more proper column type.
…mmerce_shop_order_search_fields' filter
These map to the _billing_address_index and _shipping_address_index meta keys, respectively, and contain space-delimited contents of the billing/shipping fields. Recent versions of WooCommerce do this to allow a single LIKE query rather than explicitly querying each and every column.
- Exact order IDs - The custom orders table (billing/shipping index, billing_last_name, and billing_email by default) - Post meta (if the 'woocommerce_shop_order_search_fields' filter returns any fields that don't match to columns in the order table) - Order item titles
The fix/get-customer-last-order branch has been submitted as a PR to WooCommerce (woocommerce/woocommerce#18417); once merged, we'll be able to revert to using WooCommerce's dev-master for in composer.json.
…andling of it within WooCommerce is as a Boolean. As such, update_post_meta() should convert it to a string, while get_order_data_from_table() should coerce it back into a Boolean value. This commit represents several hours of the ugliest debugging you've ever seen, crawling through the deepest, darkest corners of the WooCommerce codebase. It also represents the last failing test from the WooCommerce core test suite.
…d of the custom factories
A good portion of the code in that file was copied directly from WC_Customer_Data_Store, so it may be worth taking some time to clean things up properly in WooCommerce core, as well.
…ranch, restore WooCommerce as a dev dependency (instead of the Liquid Web fork)
WooCommerce core requires PHPUnit 6.2.3 as a development dependency which, in turn, requires PHP 7.0+ (https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.2.0). While the goal is still to support every version that WooCommerce supports (read: PHP >= 5.2), we'll leverage wimg/php-compatibility (as WooCommerce core does) to ensure that the *plugin* code is compatible with necessary versions. Meanwhile, let tests and development tooling use modern technology.
…onfiguration for coding standards + compatibility checks
…g PHP_CodeSniffer
…is only used for testing
… WooCommerce core test suite that prevents it from passing. When running WooCommerce's core test suite (with or without the custom orders table plugin) with WP_MULTISITE=1, we get the following error: 1) WC_Tests_Setup_Functions::test_wizard_in_cart_payment_gateways Failed asserting that two arrays are equal. --- Expected +++ Actual @@ @@ Array ( - 'paypal' => false + 'stripe' => true + 'ppec_paypal' => true /home/travis/build/liquidweb/woocommerce-order-tables/vendor/woocommerce/woocommerce/tests/unit-tests/setup/functions.php:38 The multisite test should remain in the test matrix as a reminder, but a failure for code we don't control shouldn't break the build.
- Enable @author tags within the plugin - Whitelist direct database usage for the customer data store - Fix instances of `require` being called as a function, rather than a language construct - Avoid double-quotes in SQL query fragments that don't need them - Use `count()` instead of `sizeof()`
…assignment within a conditional statement
Rewrite plugin to extend the default Order data store
…e-test-suite-errors
bswatson
approved these changes
Jan 12, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
I messed up on #28 and used the wrong base branch — this is all of the same code from that PR (which was approved by @bswatson), but this time based on
feature/use-woocommerce-test-tools. Once merged, we can merge #26 intodevelopand have a plugin that, you know, actually works the way it's supposed to.