From 1130df8b48a0911502c518ac2b72b0ad750f54cc Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Mon, 23 Oct 2023 17:19:01 +0200 Subject: [PATCH 1/8] Skip some tests using raw MySQL queries --- features/site-empty.feature | 1 + features/site-option.feature | 1 + 2 files changed, 2 insertions(+) diff --git a/features/site-empty.feature b/features/site-empty.feature index a55e5a902..b23938cfe 100644 --- a/features/site-empty.feature +++ b/features/site-empty.feature @@ -1,5 +1,6 @@ Feature: Empty a WordPress site of its data + @require-mysql Scenario: Empty a site Given a WP installation And I run `wp option update uploads_use_yearmonth_folders 0` diff --git a/features/site-option.feature b/features/site-option.feature index de14b84a7..18b4182b5 100644 --- a/features/site-option.feature +++ b/features/site-option.feature @@ -127,6 +127,7 @@ Feature: Manage WordPress site options """ And the return code should be 1 + @require-mysql Scenario: Filter options by `--site_id` Given a WP multisite installation From 897a38785b87be24704598181a62898df4688835 Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Mon, 23 Oct 2023 18:04:40 +0200 Subject: [PATCH 2/8] Use `TRUNCATE TABLE` This works better with the SQLite plugin right now. See https://github.com/WordPress/sqlite-database-integration/issues/51 --- src/Site_Command.php | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/Site_Command.php b/src/Site_Command.php index 1721a6248..e78010c94 100644 --- a/src/Site_Command.php +++ b/src/Site_Command.php @@ -52,8 +52,8 @@ private function empty_comments() { wp_cache_delete( $comment_id, 'comment' ); wp_cache_delete( $comment_id, 'comment_meta' ); } - $wpdb->query( "TRUNCATE $wpdb->comments" ); - $wpdb->query( "TRUNCATE $wpdb->commentmeta" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->comments" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->commentmeta" ); } /** @@ -80,8 +80,8 @@ private function empty_posts() { $posts->next(); } - $wpdb->query( "TRUNCATE $wpdb->posts" ); - $wpdb->query( "TRUNCATE $wpdb->postmeta" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->posts" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->postmeta" ); } /** @@ -110,11 +110,11 @@ private function empty_taxonomies() { wp_cache_delete( 'get', $taxonomy ); delete_option( "{$taxonomy}_children" ); } - $wpdb->query( "TRUNCATE $wpdb->terms" ); - $wpdb->query( "TRUNCATE $wpdb->term_taxonomy" ); - $wpdb->query( "TRUNCATE $wpdb->term_relationships" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->terms" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->term_taxonomy" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->term_relationships" ); if ( ! empty( $wpdb->termmeta ) ) { - $wpdb->query( "TRUNCATE $wpdb->termmeta" ); + $wpdb->query( "TRUNCATE TABLE $wpdb->termmeta" ); } } @@ -143,7 +143,7 @@ private function empty_links() { } // Empty the table once link related cache and term is removed. - $wpdb->query( "TRUNCATE {$wpdb->links}" ); + $wpdb->query( "TRUNCATE TABLE {$wpdb->links}" ); } /** From 4ba6fffb149b3522fb15e852678e5a1fc81609b5 Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Mon, 23 Oct 2023 18:08:53 +0200 Subject: [PATCH 3/8] Fix comment test Approving an approved comment works in SQLite --- features/comment.feature | 61 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) diff --git a/features/comment.feature b/features/comment.feature index 02b7b4e7e..e5746ebbe 100644 --- a/features/comment.feature +++ b/features/comment.feature @@ -158,6 +158,7 @@ Feature: Manage WordPress comments total_comments: 1 """ + @require-mysql Scenario: Approving/unapproving comments Given I run `wp comment create --comment_post_ID=1 --comment_approved=0 --porcelain` And save STDOUT as {COMMENT_ID} @@ -218,6 +219,66 @@ Feature: Manage WordPress comments """ And the return code should be 0 + # Approving an approved comment works in SQLite + @require-sqlite + Scenario: Approving/unapproving comments + Given I run `wp comment create --comment_post_ID=1 --comment_approved=0 --porcelain` + And save STDOUT as {COMMENT_ID} + + # With site url set. + When I run `wp comment approve {COMMENT_ID} --url=www.example.com` + Then STDOUT should be: + """ + Success: Approved comment {COMMENT_ID}. + """ + + When I try the previous command again + Then STDOUT should be: + """ + Success: Approved comment {COMMENT_ID}. + """ + + When I run `wp comment get --field=comment_approved {COMMENT_ID}` + Then STDOUT should be: + """ + 1 + """ + + When I run `wp comment unapprove {COMMENT_ID} --url=www.example.com` + Then STDOUT should be: + """ + Success: Unapproved comment {COMMENT_ID}. + """ + + When I run `wp comment get --field=comment_approved {COMMENT_ID}` + Then STDOUT should be: + """ + 0 + """ + + # Without site url set. + When I try `wp comment approve {COMMENT_ID}` + Then STDOUT should be: + """ + Success: Approved comment {COMMENT_ID}. + """ + And STDERR should be: + """ + Warning: Site url not set - defaulting to 'example.com'. Any notification emails sent to post author may appear to come from 'example.com'. + """ + And the return code should be 0 + + When I try `wp comment unapprove {COMMENT_ID}` + Then STDOUT should be: + """ + Success: Unapproved comment {COMMENT_ID}. + """ + And STDERR should be: + """ + Warning: Site url not set - defaulting to 'example.com'. Any notification emails sent to post author may appear to come from 'example.com'. + """ + And the return code should be 0 + Scenario: Approving/unapproving comments with multidigit comment ID Given I run `wp comment delete $(wp comment list --field=ID)` And I run `wp comment generate --count=10 --quiet` From de56a29cf9d45c1d676e819ff05f8482b91a65cc Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Mon, 23 Oct 2023 18:09:16 +0200 Subject: [PATCH 4/8] Fix post test The `post_date` field has a different format when using SQLite --- features/post.feature | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/features/post.feature b/features/post.feature index 1498bec4d..79826bd18 100644 --- a/features/post.feature +++ b/features/post.feature @@ -457,6 +457,7 @@ Feature: Manage WordPress posts 2005-01-24 09:52:00 """ + @require-mysql Scenario: Publishing a post and setting a date succeeds if the edit_date flag is passed. Given a WP install @@ -473,4 +474,23 @@ Feature: Manage WordPress posts Then STDOUT should contain: """ 2005-01-24 09:52:00 - """ \ No newline at end of file + """ + + @require-sqlite + Scenario: Publishing a post and setting a date succeeds if the edit_date flag is passed. + Given a WP install + + When I run `wp post create --post_title='test' --porcelain` + Then save STDOUT as {POST_ID} + + When I run `wp post update {POST_ID} --post_date='2005-01-24T09:52:00.000Z' --post_status='publish' --edit_date=1` + Then STDOUT should contain: + """ + Success: + """ + + When I run `wp post get {POST_ID} --field=post_date` + Then STDOUT should contain: + """ + 2005-01-24T09:52:00.000Z + """ From 2cbc6781757a2c78872794a0f49025ffa1cc4d38 Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Mon, 23 Oct 2023 18:35:04 +0200 Subject: [PATCH 5/8] Skip db check --- features/site-create.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/features/site-create.feature b/features/site-create.feature index c4cf546b5..bfc9ecbc7 100644 --- a/features/site-create.feature +++ b/features/site-create.feature @@ -16,7 +16,7 @@ Feature: Create a new site on a WP multisite define( 'BLOG_ID_CURRENT_SITE', 1 ); """ - When I run `wp core config {CORE_CONFIG_SETTINGS} --extra-php < extra-config` + When I run `wp config create {CORE_CONFIG_SETTINGS} --skip-check --extra-php < extra-config` Then STDOUT should be: """ Success: Generated 'wp-config.php' file. From a9132a5a25ad3d8725b25f547fb2e5a6f72f0cb0 Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Mon, 23 Oct 2023 18:35:41 +0200 Subject: [PATCH 6/8] Skip test --- features/user-application-password.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/features/user-application-password.feature b/features/user-application-password.feature index 635a0706c..216a7c317 100644 --- a/features/user-application-password.feature +++ b/features/user-application-password.feature @@ -1,6 +1,6 @@ Feature: Manage user custom fields - @less-than-php-8.0 + @less-than-php-8.0 @require-mysql Scenario: User application passwords are disabled for WordPress lower than 5.6 Given a WP install And I try `wp theme install twentytwenty --activate` From f68361a4769b33b18c0fd06c444459b4891d2439 Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Mon, 23 Oct 2023 18:37:10 +0200 Subject: [PATCH 7/8] Add comment --- features/user-application-password.feature | 1 + 1 file changed, 1 insertion(+) diff --git a/features/user-application-password.feature b/features/user-application-password.feature index 216a7c317..eb30311fd 100644 --- a/features/user-application-password.feature +++ b/features/user-application-password.feature @@ -1,5 +1,6 @@ Feature: Manage user custom fields + # SQLite requires WordPress 6.0+. @less-than-php-8.0 @require-mysql Scenario: User application passwords are disabled for WordPress lower than 5.6 Given a WP install From cb25bb5bb60aee0f028d734a37f0c5f97429c22e Mon Sep 17 00:00:00 2001 From: Pascal Birchler Date: Fri, 10 Nov 2023 10:47:49 +0100 Subject: [PATCH 8/8] Add link to issue --- features/post.feature | 3 +++ 1 file changed, 3 insertions(+) diff --git a/features/post.feature b/features/post.feature index 79826bd18..e1f4ec34b 100644 --- a/features/post.feature +++ b/features/post.feature @@ -476,6 +476,9 @@ Feature: Manage WordPress posts 2005-01-24 09:52:00 """ + # Separate test because of a known bug in the SQLite plugin. + # See https://github.com/WordPress/sqlite-database-integration/issues/52. + # Once the bug is resolved, this separate test can be removed again. @require-sqlite Scenario: Publishing a post and setting a date succeeds if the edit_date flag is passed. Given a WP install