Skip to content

Commit 9408392

Browse files
schlesseraschlessera
authored
Merge pull request #637 from wp-cli/claude/wp-cli-issue-5286-n50evd-silent-noop
Apply parameters that user create and post update silently discard
2 parents 741ad38 + b3b3d7d commit 9408392

6 files changed

Lines changed: 542 additions & 4 deletions

File tree

‎README.md‎

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8422,7 +8422,9 @@ wp user create <user-login> <user-email> [--role=<role>] [--user_pass=<password>
84228422
A string containing content about the user.
84238423

84248424
[--rich_editing=<rich_editing>]
8425-
A string for whether to enable the rich editor or not. False if not empty.
8425+
Whether to enable the rich editor for the user. Accepts 'true' or 'false',
8426+
or their numeric forms 1 and 0.
8427+
Default: true
84268428

84278429
[--send-email]
84288430
Send an email to the user with their new account details.
@@ -10089,7 +10091,8 @@ wp user update <user>... [--user_pass=<password>] [--user_nicename=<nice_name>]
1008910091
A string containing content about the user.
1009010092

1009110093
[--rich_editing=<rich_editing>]
10092-
A string for whether to enable the rich editor or not. False if not empty.
10094+
Whether to enable the rich editor for the user. Accepts 'true' or
10095+
'false' as a string literal, not boolean.
1009310096

1009410097
[--syntax_highlighting=<syntax_highlighting>]
1009510098
Whether to enable the rich code editor for the user. Accepts 'true' or

‎features/post-create-duplicate.feature‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -79,3 +79,34 @@ Feature: Create Duplicate WordPress post from existing posts.
7979
Then STDOUT should be a table containing rows:
8080
| Field | Value |
8181
| post_type | page |
82+
83+
Scenario: Duplicating a post does not inherit its modification date
84+
Given a WP install
85+
86+
When I run `wp post create --post_title='Source' --post_status=publish --porcelain`
87+
Then STDOUT should be a number
88+
And save STDOUT as {SOURCE_ID}
89+
90+
When I run `wp post update {SOURCE_ID} --post_modified='2015-03-03 09:00:00'`
91+
Then STDOUT should not be empty
92+
93+
When I run `wp post create --from-post={SOURCE_ID} --post_title='Duplicate' --porcelain`
94+
Then STDOUT should be a number
95+
And save STDOUT as {DUPLICATE_ID}
96+
97+
When I run `wp post get {DUPLICATE_ID} --field=post_modified`
98+
Then STDOUT should not contain:
99+
"""
100+
2015-03-03
101+
"""
102+
103+
# An explicit modification date still wins over the source post's.
104+
When I run `wp post create --from-post={SOURCE_ID} --post_title='Dated duplicate' --post_modified='2016-04-04 10:00:00' --porcelain`
105+
Then STDOUT should be a number
106+
And save STDOUT as {DATED_DUPLICATE_ID}
107+
108+
When I run `wp post get {DATED_DUPLICATE_ID} --field=post_modified`
109+
Then STDOUT should be:
110+
"""
111+
2016-04-04 10:00:00
112+
"""

‎features/post.feature‎

Lines changed: 274 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -878,3 +878,277 @@ Feature: Manage WordPress posts
878878
"""
879879
2
880880
"""
881+
882+
Scenario: Set a post's modification date on update
883+
Given a WP install
884+
885+
# A timezone with an offset, so the GMT value derived from the local one is
886+
# distinguishable from it. 1 January is outside DST in New York.
887+
When I run `wp option update timezone_string 'America/New_York'`
888+
Then STDOUT should not be empty
889+
890+
When I run `wp post create --post_title='A post' --post_status=publish --porcelain`
891+
Then STDOUT should be a number
892+
And save STDOUT as {POST_ID}
893+
894+
When I run `wp post update {POST_ID} --post_modified='2020-01-01 12:00:00'`
895+
Then STDOUT should be:
896+
"""
897+
Success: Updated post {POST_ID}.
898+
"""
899+
900+
When I run `wp post get {POST_ID} --field=post_modified`
901+
Then STDOUT should be:
902+
"""
903+
2020-01-01 12:00:00
904+
"""
905+
906+
When I run `wp post get {POST_ID} --field=post_modified_gmt`
907+
Then STDOUT should be:
908+
"""
909+
2020-01-01 17:00:00
910+
"""
911+
912+
Scenario: Set a post's modification date on create
913+
Given a WP install
914+
915+
When I run `wp option update timezone_string 'America/New_York'`
916+
Then STDOUT should not be empty
917+
918+
When I run `wp post create --post_title='Another post' --post_date='2019-05-05 10:00:00' --post_modified='2020-01-01 12:00:00' --porcelain`
919+
Then STDOUT should be a number
920+
And save STDOUT as {POST_ID}
921+
922+
When I run `wp post get {POST_ID} --field=post_modified`
923+
Then STDOUT should be:
924+
"""
925+
2020-01-01 12:00:00
926+
"""
927+
928+
When I run `wp post get {POST_ID} --field=post_modified_gmt`
929+
Then STDOUT should be:
930+
"""
931+
2020-01-01 17:00:00
932+
"""
933+
934+
Scenario: A post's modification date defaults to the current time
935+
Given a WP install
936+
937+
# Given a known modification date, so that an update which failed to set one
938+
# would leave this value behind and be caught.
939+
When I run `wp post create --post_title='Undated post' --post_status=publish --post_modified='2019-02-03 04:05:06' --porcelain`
940+
Then STDOUT should be a number
941+
And save STDOUT as {POST_ID}
942+
943+
When I run `wp post get {POST_ID} --field=post_modified`
944+
Then STDOUT should be:
945+
"""
946+
2019-02-03 04:05:06
947+
"""
948+
949+
When I run `wp post update {POST_ID} --post_title='Retitled'`
950+
Then STDOUT should be:
951+
"""
952+
Success: Updated post {POST_ID}.
953+
"""
954+
955+
When I run `wp post get {POST_ID} --field=post_modified`
956+
Then STDOUT should not contain:
957+
"""
958+
2019-02-03 04:05:06
959+
"""
960+
And STDOUT should not be empty
961+
962+
Scenario: Setting only the GMT modification date derives the local one
963+
Given a WP install
964+
965+
# A timezone with an offset, so the derived local value is distinguishable
966+
# from the GMT one it was derived from. 1 January is outside DST in New York.
967+
When I run `wp option update timezone_string 'America/New_York'`
968+
Then STDOUT should not be empty
969+
970+
When I run `wp post create --post_title='GMT only' --post_status=publish --post_modified_gmt='2020-01-01 12:00:00' --porcelain`
971+
Then STDOUT should be a number
972+
And save STDOUT as {POST_ID}
973+
974+
When I run `wp post get {POST_ID} --field=post_modified_gmt`
975+
Then STDOUT should be:
976+
"""
977+
2020-01-01 12:00:00
978+
"""
979+
980+
When I run `wp post get {POST_ID} --field=post_modified`
981+
Then STDOUT should be:
982+
"""
983+
2020-01-01 07:00:00
984+
"""
985+
986+
# And the same on update, which takes the other of the two code paths.
987+
When I run `wp post update {POST_ID} --post_modified_gmt='2020-06-01 12:00:00'`
988+
Then STDOUT should be:
989+
"""
990+
Success: Updated post {POST_ID}.
991+
"""
992+
993+
When I run `wp post get {POST_ID} --field=post_modified_gmt`
994+
Then STDOUT should be:
995+
"""
996+
2020-06-01 12:00:00
997+
"""
998+
999+
# June is inside DST, so the offset is four hours rather than five.
1000+
When I run `wp post get {POST_ID} --field=post_modified`
1001+
Then STDOUT should be:
1002+
"""
1003+
2020-06-01 08:00:00
1004+
"""
1005+
1006+
Scenario: An invalid modification date is rejected on create
1007+
Given a WP install
1008+
1009+
When I try `wp post create --post_title='Bad date' --post_status=publish --post_modified='banana'`
1010+
Then the return code should be 1
1011+
And STDERR should be:
1012+
"""
1013+
Error: Invalid date.
1014+
"""
1015+
1016+
When I try `wp post create --post_title='Bad GMT date' --post_status=publish --post_modified_gmt='banana'`
1017+
Then the return code should be 1
1018+
And STDERR should be:
1019+
"""
1020+
Error: Invalid date.
1021+
"""
1022+
1023+
# Well-formed but not a real calendar date.
1024+
When I try `wp post create --post_title='Bad calendar date' --post_status=publish --post_modified='2020-02-30 12:00:00'`
1025+
Then the return code should be 1
1026+
And STDERR should be:
1027+
"""
1028+
Error: Invalid date.
1029+
"""
1030+
1031+
When I run `wp post list --s=Bad --format=count`
1032+
Then STDOUT should be:
1033+
"""
1034+
0
1035+
"""
1036+
1037+
Scenario: An invalid modification date is rejected on update
1038+
Given a WP install
1039+
1040+
When I run `wp post create --post_title='A post' --post_status=publish --post_modified='2020-01-01 12:00:00' --porcelain`
1041+
Then STDOUT should be a number
1042+
And save STDOUT as {POST_ID}
1043+
1044+
When I try `wp post update {POST_ID} --post_modified='banana'`
1045+
Then the return code should be 1
1046+
And STDERR should be:
1047+
"""
1048+
Warning: Invalid date.
1049+
"""
1050+
1051+
When I try `wp post update {POST_ID} --post_modified_gmt='banana'`
1052+
Then the return code should be 1
1053+
And STDERR should be:
1054+
"""
1055+
Warning: Invalid date.
1056+
"""
1057+
1058+
When I run `wp post get {POST_ID} --field=post_modified`
1059+
Then STDOUT should be:
1060+
"""
1061+
2020-01-01 12:00:00
1062+
"""
1063+
1064+
When I run `wp post get {POST_ID} --field=post_modified_gmt`
1065+
Then STDOUT should be:
1066+
"""
1067+
2020-01-01 12:00:00
1068+
"""
1069+
1070+
Scenario: Set an attachment's modification date
1071+
Given a WP install
1072+
1073+
# Attachments take the wp_insert_attachment_data filter rather than
1074+
# wp_insert_post_data, so they are a separate path to cover.
1075+
When I run `wp post create --post_type=attachment --post_title='An attachment' --post_mime_type=image/png --post_modified='2020-01-01 12:00:00' --porcelain`
1076+
Then STDOUT should be a number
1077+
And save STDOUT as {ATTACHMENT_ID}
1078+
1079+
When I run `wp post get {ATTACHMENT_ID} --field=post_modified`
1080+
Then STDOUT should be:
1081+
"""
1082+
2020-01-01 12:00:00
1083+
"""
1084+
1085+
When I run `wp post update {ATTACHMENT_ID} --post_modified='2021-02-02 13:00:00'`
1086+
Then STDOUT should be:
1087+
"""
1088+
Success: Updated post {ATTACHMENT_ID}.
1089+
"""
1090+
1091+
When I run `wp post get {ATTACHMENT_ID} --field=post_modified`
1092+
Then STDOUT should be:
1093+
"""
1094+
2021-02-02 13:00:00
1095+
"""
1096+
1097+
Scenario: A post inserted by a save hook keeps its own modification date
1098+
Given a WP install
1099+
And a wp-content/mu-plugins/test-save-hook.php file:
1100+
"""
1101+
<?php
1102+
// Plugin Name: Test Save Hook
1103+
add_action(
1104+
'save_post',
1105+
function ( $post_id, $post ) {
1106+
if ( 'Trigger' !== $post->post_title || 'revision' === $post->post_type ) {
1107+
return;
1108+
}
1109+
wp_insert_post(
1110+
[
1111+
'post_title' => 'Inserted by hook',
1112+
'post_status' => 'publish',
1113+
]
1114+
);
1115+
},
1116+
10,
1117+
2
1118+
);
1119+
"""
1120+
1121+
When I run `wp post create --post_title='Trigger' --post_status=publish --post_modified='2020-01-01 12:00:00' --porcelain`
1122+
Then STDOUT should be a number
1123+
And save STDOUT as {POST_ID}
1124+
1125+
When I run `wp post update {POST_ID} --post_modified='2021-02-02 13:00:00'`
1126+
Then STDOUT should be:
1127+
"""
1128+
Success: Updated post {POST_ID}.
1129+
"""
1130+
1131+
When I run `wp post get {POST_ID} --field=post_modified`
1132+
Then STDOUT should be:
1133+
"""
1134+
2021-02-02 13:00:00
1135+
"""
1136+
1137+
# The hook ran once for the create and once for the update, and neither of
1138+
# the posts it inserted should carry the date the command asked for.
1139+
When I run `wp post list --title='Inserted by hook' --format=count`
1140+
Then STDOUT should be:
1141+
"""
1142+
2
1143+
"""
1144+
1145+
When I run `wp post list --title='Inserted by hook' --field=post_modified`
1146+
Then STDOUT should not contain:
1147+
"""
1148+
2020-01-01
1149+
"""
1150+
And STDOUT should not contain:
1151+
"""
1152+
2021-02-02
1153+
"""
1154+
And STDOUT should not be empty

0 commit comments

Comments
 (0)