Fix/missing wp user type #988

eddiesshop · 2023-08-26T02:27:44Z

Description

I came across this bug when attempting to do the following:

$author_data = [
    'wp_user_nicename', // WP User who also happens to be a Guest Author
    'guest_author_only_nicename'
];
$coauthors_plus->add_coauthors( $post_id, $author_data, $append = false );

I placed my WP_User first in the array because of this block of code. It will update the wp_posts.post_author column for the first WP_User it finds.

However, I noticed that the wp_posts.post_author column was not being updated as I was expecting.

I started digging through the code and found that this block of code was essentially being skipped, due to the fact that this function always returns a Guest Author object.

This is actually causing the add_coauthors function to always respond with false for instances where wp_posts.post_author = 0 or where the user no longer exists on the system. Even if you're passing in a valid WP_User who is also a Guest Author, it would respond with false, as was my case.

With this fix, we retain the fact that the original user_nicename we passed is also a WP_User. In this way, we don't waste compute cycles in that foreach loop where it would never find a valid WP_User it's trying to look for.

Deploy Notes

Are there any new dependencies added that should be taken into account when deploying to WordPress.org?
No

Steps to Test

Outline the steps to test and verify the PR here.

You will need 5 authors:

WP_User who is not linked to Guest Author ( user_nicename: wp_user_1 )
WP_User who is not linked to Guest Author ( user_nicename: wp_user_2 )
Guest Author who is not linked ( user_nicename: ga_1 )
Guest Author who is not linked ( user_nicename: ga_2 )
WP_User who is linked to Guest Author ( user_nicename: wp_user_and_ga_1 )

Example:

Check out PR.
Instantiate CoAuthor_Plus: $cap = new CoAuthor_plus();
Execute $cap->add_coauthors( $post_id, [ 'wp_user_1' ] ); result should be true. wp_posts.post_author should be equal to wp_users.ID
Execute $cap->add_coauthors( $post_id, [ 'ga_1', 'ga_2' ] ); result should be false. This is because $append = false and there was no wp_user passed as a CoAuthor. Notice also that wp_posts.post_author remains untouched.
Execute Step 1 again, then execute Step 4 again, this time passing $append = true, like so: $cap->add_coauthors( $post_id, [ 'ga_1', 'ga_2' ], true ); result should be true. Notice, that all 3 authors are correctly displayed.
Execute $cap->add_coauthors( $post_id, [ 'ga_1', 'wp_user_2' ], true ); result should be true. Notice that wp_posts.post_author is not overwritten. This is because we are appending authors to the post.
Execute $cap->add_coauthors( $post_id, [ 'ga_2', 'wp_user_and_ga_1' ] ); result should be true. Notice here that the WP_User is placed second in the array, but it is correctly picked up now, and the wp_posts.post_author column is correctly updated to match the user's wp_users.ID column.

eddiesshop · 2023-08-31T02:14:59Z

The previous 2 commits address another issue I found during some internal testing.

What was happening was that using get_coauthor_by and searching with a Guest Author, if that Guest Author has a valid link to a WP_User, it is summarily ignored. Functions like add_coauthors expect at least one coauthor to be a valid WP_User so that the wp_posts.post_author column can be appropriately updated. The only case where this function is returning an expected value is when you search by the WP_User first. When it arrives at $guest_author = $this->guest_authors->get_guest_author_by( $key, $value, $force );, $guest_author === false. It is then forced to move to the switch statement to find a user via their WP_User data.

With this refactor, when you arrive at $guest_author = $this->guest_authors->get_guest_author_by( $key, $value, $force ); and a valid $guest_author is obtained, it will now check if the linked_account attribute is set. If so, it will attempt to find the corresponding user for the Guest Account. Crucially, this change still gives priority to returning a Guest Author first and foremost. Only when a Guest Author is not found, will it search for a WP_User. If found, it will also search to see if a linked Guest Author account exists. If it does, it will return that Guest Author object instead, without losing the fact that this account also has a WP_User associated with it. If the plugin is disabled, then it will attempt to find a WP_User.

So using the examples outlined in the description, the below scenario should be tested as well:
8. Execute $cap->add_coauthors( $post_id, [ 'wp_user_2', 'ga_1', 'wp_user_and_ga_1' ] ); result should be true. Notice that wp_posts.post_author is equal to the ID for wp_user_2. Also, all 3 authors can be found when looking at the terms associated to $post_id.
9. Execute $cap->add_coauthors( $post_id, [ 'wp_user_and_ga_1', 'ga_1', 'wp_user_2' ] ); result should be same as above, except now wp_posts.post_author is linked to wp_user_and_ga_1.
10. Execute $cap->add_coauthors( $post_id, [ 'ga_1' ] ); result should be false. Since this is a pure GA account, wp_post.post_author is not updated, however we can see a term-taxonomy associated with this $post_id. Follow this up by executing $cap->add_coauthors( $post_id, [ 'wp_user_2', 'wp_user_and_ga_1' ], true ); the result should be true. Notice that wp_posts.post_author is equal to wp_user_2's user ID.

GaryJones · 2023-08-31T07:23:21Z

Thanks @eddiesshop. A couple of quick meta questions:

Should/Can the fix for the extra issue go into a new PR?
Since most of the steps are to execute code, could you please add suitable tests (happy and sad paths) for each fix?

This might be a problematic decision. But the way I justify this change is that if you are appending co-authors, there may already be a WP_User set as the author. So we don't really have to care whether one is passed or not. Because of this, we do not need to forcibly return a `false` flag since that is confusing to the caller, especially because we actually do save the guest authors which are given in the call! Instead, if the $append flag is false, we should expect that at least one user will be a WP_User. In that case, if none is passed in, then there is a mismatch of the intended authors. Because now, the `wp_posts.post_author` column will have an old `wp_users.ID` which remains set and most likely isn't the intent of the caller.

Also, returning the actual response from the DB, to make this call even more accurate in terms of what is actually happen at the DB layer.

A pure WP_User (i.e. a WP_User that IS NOT linked to a Guest Author) needs to be handled specially.

This refactor is absolutely necessary in order for all the previous fixes to work as expected. Without this fix, what happens is that when you use `get_coauthor_by` by searching with a Guest Author, if that Guest Author has a valid link to a WP_User, it is summarily ignored. Functions like `add_coauthors` expect at least one coauthor to be a valid WP_User so that the `wp_posts.post_author` column can be appropriately updated. The only case where this function is returning an expected value is when you search by the WP_User first. When it arrives at `$guest_author = $this->guest_authors->get_guest_author_by( $key, $value, $force );`, `$guest_author === false`. It is then forced to move to the switch statement to find a user via their WP_User data. With this refactor, `get_coauthor_by` will now check if the `linked_account` attribute is set. If so, it will attempt to find the corresponding user for the Guest Account. It still gives priority to returning a Guest Author. When a Guest Author is not found, it will search for a WP_User. If found, it will also search to see if a linked Guest Author account exists. If it does, it will return that Guest Author object instead, without losing the fact that this account also has a WP_User associated with it.

I forgot to run tests on my previous commit. This satisfies the test Test_CoAuthors_Plus::test_get_coauthor_by_when_guest_authors_not_enabled which is expecting a WP_User when the plugin is not enabled.

This might be a problematic decision. But the way I justify this change is that if you are appending co-authors, there may already be a WP_User set as the author. So we don't really have to care whether one is passed or not. Because of this, we do not need to forcibly return a `false` flag since that is confusing to the caller, especially because we actually do save the guest authors which are given in the call! Instead, if the $append flag is false, we should expect that at least one user will be a WP_User. In that case, if none is passed in, then there is a mismatch of the intended authors. Because now, the `wp_posts.post_author` column will have an old `wp_users.ID` which remains set and most likely isn't the intent of the caller.

Also, returning the actual response from the DB, to make this call even more accurate in terms of what is actually happen at the DB layer.

A pure WP_User (i.e. a WP_User that IS NOT linked to a Guest Author) needs to be handled specially.

This refactor is absolutely necessary in order for all the previous fixes to work as expected. Without this fix, what happens is that when you use `get_coauthor_by` by searching with a Guest Author, any link to a WP_User the Guest Author may have is summarily ignored. Functions like `add_coauthors` expect at least one coauthor to be a valid WP_User so that the `wp_posts.post_author` column can be appropriately updated. The only case where this function is currently returning an expected value is when you search by a WP_User account/field first. When it arrives at `$guest_author = $this->guest_authors->get_guest_author_by( $key, $value, $force );`, `$guest_author === false`. It is then forced to move to the switch statement to find a user via their WP_User data. With this refactor, `get_coauthor_by` will now check if the `linked_account` attribute is set. If so, it will then attempt to find the corresponding WP_User for the Guest Author. Crucially, it still gives priority to returning a Guest Author. When a Guest Author is not found, it will then attempt to search for a WP_User. If found, it will also search to see if a linked Guest Author account exists. If it does, it will return that Guest Author object instead, without losing the fact that this account also has a WP_User associated with it.

These user_login's were causing other tests to fail because you cannot create another user with the same user_login.

Older version of PHPUnit do not have this function available. Updating to workaround: `assertTrue( property_exists( $obj, 'prop' ) )`

GaryJones

Hi @eddiesshop - thank you for your patience as I reviewed it.

I appreciate the effort gone into creating all the tests, and seeing them pass really helps me to be confident that the expected behaviour for add_coauthors() would work as intended.

The beauty of tests lies in keeping things granular, and not making repeated assertions as they add to the noise and make it much harder to see what the real focus of a test is. Keeping the "Arrange, Act, Assert" structure in mind helps to ensure that the assertions are only happening after the key act (in this case, usually the call to add_coauthors()) has happened. Earlier tests may also assert before the act as well if we need to confirm the WP core default behaviour around the factory generations.

php/class-coauthors-plus.php

tests/test-coauthors-plus.php

GaryJones · 2023-09-17T13:21:03Z

tests/test-coauthors-plus.php

+
+		$this->assertEquals( 1, $query->found_posts );
+		$this->assertEquals( $this->author1->ID, $query->posts[0]->post_author );


Suggested change

$this->assertEquals( 1, $query->found_posts );

$this->assertEquals( $this->author1->ID, $query->posts[0]->post_author );

GaryJones · 2023-09-17T13:34:10Z

tests/test-coauthors-plus.php

+		$linked_author_1 = $this->_cap->get_coauthor_by( 'id', $this->author2->ID );
+		$this->assertIsObject( $linked_author_1 );
+		$this->assertThat(
+			$linked_author_1,
+			$this->logicalNot(
+				$this->isInstanceOf( WP_User::class )
+			)
+		);
+		$this->assertTrue( property_exists( $linked_author_1, 'type' ) );
+		$this->assertEquals( 'guest-author', $linked_author_1->type );
+		$this->assertTrue( property_exists( $linked_author_1, 'is_wp_user' ) );
+		$this->assertTrue( $linked_author_1->is_wp_user );
+		$this->assertTrue( property_exists( $linked_author_1, 'wp_user' ) );
+		$this->assertInstanceOf( WP_User::class, $linked_author_1->wp_user );
+		$this->assertEquals( $this->author2->ID, $linked_author_1->wp_user->ID );


It strongly feels like these assertions should go into a test specifically for get_coauthor_by() - so that this test method can just call the happy path of get_coauthor_by() and focus on what happens when the guest author is added with add_coauthors(). i.e. the whole test should be something like:

// Arrange: // Create linked guest author from User 1. // Create linked guest author from User 2. // Create post with Editor 1 as the author. // Act: // Add both guest authors to the post. // Assert: // Assert the post author is User 1.

That should be it. All the other assertions should be handled (happy and sad paths) in other tests. The only thing this test should be doing is adding multiple ordered linked tests and see if the post_author field was updated.

GaryJones · 2023-09-17T13:34:45Z

tests/test-coauthors-plus.php

+	}
+
+	/**
+	 * Very similar test as before. The only difference is that we are appending,


Data provider please.

GaryJones · 2023-09-17T13:39:17Z

tests/test-coauthors-plus.php

+	}
+
+	/**
+	 * Here we are testing a similar scenario as above, except we are passing the linked user's WP_User login field


If the test is to check that a user_login field is correctly converted, and applied, then you only need two users at most, and it can be simplified down.

The reason I added 3 authors is to ensure and signify that the functionality behaves correctly, as expected, no matter how many authors are passed during assignment. This ensures that, in the future, should a code change come along that uses array_shift or array_pop, this test would fail, because the function is not picking up the correct author for linkage.

GaryJones · 2023-09-17T13:43:38Z

tests/test-coauthors-plus.php

+	 * This test is a combination of a few different aspects that establish some expected plugin behavior.
+	 * Two posts are created to test with. Both have no WP_User as the author (i.e. wp_posts.post_author = 0).
+	 * For the first post:
+	 * 1. A guest author is created, and assigned to the post.
+	 * 2. Since there is no WP_User which is passed, and the GA is NOT being appended, the result should be false.
+	 * 3. The wp_posts.post_author column should still be 0 since this is a GA and not a WP_User or a linked GA.
+	 *
+	 * For the second post:
+	 * 1. A guest author is created, and appended to the post.
+	 * 2. Since we are appending a coauthor, it does not matter if there was already a WP_User author, so result should be true.
+	 * 3. The wp_posts.post_author column should still be 0 since this is a GA and not a WP_User or a linked GA.
+	 *
+	 * Going back to the first post:
+	 * 1. A linked user and a WP_User are created and assigned to this post.
+	 * 2. Result should be true since here we essentially have 2 WP_Users.
+	 * 3. Since there is a WP_User, and it is passed first, the wp_posts.post_author column should be set to the ID for that WP_User.
+	 * 4. There should only be 2 author terms for this post, one for the WP_User, and one for the linked account.
+	 * The term for the GA which was previously assigned is deleted.
+	 *
+	 * Finally, going back to the second post:
+	 * 1. A linked user and a WP_User are created and appended to this post.
+	 * 2. Result should be true since we have 2 WP_Users.
+	 * 3. Here we passed the linked author first, so the wp_posts.post_author column should match the ID for the linked WP_user account.
+	 * 4. There should be 3 author terms for this post, one for the GA, the WP_user, and linked account.


I greatly appreciate the extra documentation on this test method. But, other than behaviour around when a post starts off with post_author = 0, what else is being tested here that hasn't already been tested above?

I deleted this test after realizing, after your comment, that it isn't doing anything that hasn't already been tested with the new tests that were added.

Relying instead on wp_user property which has already been used before.

By fully testing CoAuthorPlus::get_coauthor_by(), we can remove some repetitive assertions that don't directly relate to what's being tested.

changes in the tests were applied

* Increase composer.json required PHP version to 7.4 * Update README to match required PHP version 7.4 * Remove PHP 7.1 from integration tests * PHP 7.4: Use array_key_first() Slightly cleaner to use the native function for getting the first key's value from an array. * PHP 7.4: Use instanceof * PHP 7.4: Use null coalescing * PHP 7.4: Add return types * PHP 7.4: Collapse nested dirname() calls * CI: Remove MySQL workaround for PHP <= 7.3 * Increase WordPress required version to 5.9 * Update integration tests to use WordPress 5.9 * Remove unnecessary phpunit versions for WordPress 5.9 * CI: Update tested versions Doesn't make sense to test WP versions would unsupported PHP versions (e.g. WP 5.9 with PHP 8.3). * Composer: Update dev-dependencies * PHPCS: Consolidate config into config file The PHPCS in the composer.json was duplicating but obscuring some aspects of what was in the `phpcs.xml.dist` file. This change consolidates the Composer commands and the config file. * Support for Yoast %%name%% variable * CI: Update deploy.yml Increase actions/checkout dependency version. * CI: Update integrate.yml action versios * Contents edited to consolidate instructions within the Wiki and bring more attention to its existence (#1055) * add: created a new CLI cmd to backfill missing author terms for posts. (#1060) * add: created a new CLI cmd to backfill missing author terms for posts. * add: adding some comments to the new and old backfill commands. The comments are meant to clarify the key differences between the two commands, and that the new one should be preferred over the old one. * add: batching is the default, pass `--unbatched` flag to run w/o it. --------- Co-authored-by: Gary Jones <[email protected]> Co-authored-by: Alec Geatches <[email protected]> * Fix/missing wp user type (#988) * fix: preventing loss of fact that a guest author might also be a WP_User * fix: making the update operation dependent on $append flag. This might be a problematic decision. But the way I justify this change is that if you are appending co-authors, there may already be a WP_User set as the author. So we don't really have to care whether one is passed or not. Because of this, we do not need to forcibly return a `false` flag since that is confusing to the caller, especially because we actually do save the guest authors which are given in the call! Instead, if the $append flag is false, we should expect that at least one user will be a WP_User. In that case, if none is passed in, then there is a mismatch of the intended authors. Because now, the `wp_posts.post_author` column will have an old `wp_users.ID` which remains set and most likely isn't the intent of the caller. * fix: attempting DB update only when $new_author is not empty. Also, returning the actual response from the DB, to make this call even more accurate in terms of what is actually happen at the DB layer. * fix: need to ensure pure WP_User is processed correctly as post_author. A pure WP_User (i.e. a WP_User that IS NOT linked to a Guest Author) needs to be handled specially. * fix: a necessary refactor of the `get_coauthor_by` function. This refactor is absolutely necessary in order for all the previous fixes to work as expected. Without this fix, what happens is that when you use `get_coauthor_by` by searching with a Guest Author, if that Guest Author has a valid link to a WP_User, it is summarily ignored. Functions like `add_coauthors` expect at least one coauthor to be a valid WP_User so that the `wp_posts.post_author` column can be appropriately updated. The only case where this function is returning an expected value is when you search by the WP_User first. When it arrives at `$guest_author = $this->guest_authors->get_guest_author_by( $key, $value, $force );`, `$guest_author === false`. It is then forced to move to the switch statement to find a user via their WP_User data. With this refactor, `get_coauthor_by` will now check if the `linked_account` attribute is set. If so, it will attempt to find the corresponding user for the Guest Account. It still gives priority to returning a Guest Author. When a Guest Author is not found, it will search for a WP_User. If found, it will also search to see if a linked Guest Author account exists. If it does, it will return that Guest Author object instead, without losing the fact that this account also has a WP_User associated with it. * fix: returning a plain WP_User if guest authors is not enabled. I forgot to run tests on my previous commit. This satisfies the test Test_CoAuthors_Plus::test_get_coauthor_by_when_guest_authors_not_enabled which is expecting a WP_User when the plugin is not enabled. * feat: adding additional tests for co-authors-plus.php functionality. * fix: preventing loss of fact that a guest author might also be a WP_User * fix: making the update operation dependent on $append flag. This might be a problematic decision. But the way I justify this change is that if you are appending co-authors, there may already be a WP_User set as the author. So we don't really have to care whether one is passed or not. Because of this, we do not need to forcibly return a `false` flag since that is confusing to the caller, especially because we actually do save the guest authors which are given in the call! Instead, if the $append flag is false, we should expect that at least one user will be a WP_User. In that case, if none is passed in, then there is a mismatch of the intended authors. Because now, the `wp_posts.post_author` column will have an old `wp_users.ID` which remains set and most likely isn't the intent of the caller. * fix: attempting DB update only when $new_author is not empty. Also, returning the actual response from the DB, to make this call even more accurate in terms of what is actually happen at the DB layer. * fix: need to ensure pure WP_User is processed correctly as post_author. A pure WP_User (i.e. a WP_User that IS NOT linked to a Guest Author) needs to be handled specially. * fix: a necessary refactor of the get_coauthor_by function. This refactor is absolutely necessary in order for all the previous fixes to work as expected. Without this fix, what happens is that when you use `get_coauthor_by` by searching with a Guest Author, any link to a WP_User the Guest Author may have is summarily ignored. Functions like `add_coauthors` expect at least one coauthor to be a valid WP_User so that the `wp_posts.post_author` column can be appropriately updated. The only case where this function is currently returning an expected value is when you search by a WP_User account/field first. When it arrives at `$guest_author = $this->guest_authors->get_guest_author_by( $key, $value, $force );`, `$guest_author === false`. It is then forced to move to the switch statement to find a user via their WP_User data. With this refactor, `get_coauthor_by` will now check if the `linked_account` attribute is set. If so, it will then attempt to find the corresponding WP_User for the Guest Author. Crucially, it still gives priority to returning a Guest Author. When a Guest Author is not found, it will then attempt to search for a WP_User. If found, it will also search to see if a linked Guest Author account exists. If it does, it will return that Guest Author object instead, without losing the fact that this account also has a WP_User associated with it. * fix: renaming user_login's for new authors introduced for new tests. These user_login's were causing other tests to fail because you cannot create another user with the same user_login. * fix: removing use of assertObjectHasProperty Older version of PHPUnit do not have this function available. Updating to workaround: `assertTrue( property_exists( $obj, 'prop' ) )` * fix: typo in function call * fix: using strict comparison instead of function call `is_null` * fix: using more descriptive assertion for array validation. * fix: using `create_and_get` post factory func, to avoid query call. * fix: removing use of newly introduced is_wp_user property. Relying instead on wp_user property which has already been used before. * fix: PHPCS fixes and added commentary/descriptions to docblocks. * fix: some small quick fixes for formatting and documentation * fix: removing repetitive test. * add: new assertion func that determines if an obj is not a WP_User class * add: new assertion to help determine if a Post has the correct Authors * add: new test solely for CoAuthorPlus::get_coauthor_by(). By fully testing CoAuthorPlus::get_coauthor_by(), we can remove some repetitive assertions that don't directly relate to what's being tested. * fix: was passing string values when I should've been passing Author objs * fix: using a data provider for very similar tests --------- Co-authored-by: Gary Jones <[email protected]> * bumping version to 3.6.2 (#1064) * bumping version to 3.6.2 * Update CHANGELOG.md Co-authored-by: Gary Jones <[email protected]> * add changelog link --------- Co-authored-by: Gary Jones <[email protected]> * fix: prevent the backfill from running forever. (#1065) * fix: prevent the backfill from running forever. There's an edge case where an author that no longer exists can still be assigned to a post. This throws the backfill script into an infinite loop, because the respective author-term is never found/created, and so the underlying problem of missing author-term records is never resolved. The infinite loop is started when at the end of the while loop, the script asks for "remaining posts which need author terms" and so it returns the same rows over and over. This fix addresses this in 2 ways: 1. If an author is not found, we look for the most prolific author on the site and assign the posts to them. If there is no prolific author, one is created. And if one can't be created, an exception is thrown so that the script can't proceed. 2. Checks have been added so that the script can't go beyond what should be the maximum number of rows needing to be addressed. * fix: obtaining the first available admin user account instead. * fix: updating output to reflect that the ID belongs to an Admin account. * fix: this function should be private * fix: switching tactic to skipping posts that have missing post_author. This approach is more faithful with what the current condition on the site would be anyway. If the post author doesn't exist on the site, you wouldn't be able to see the particular post in question in an author archive anyway. Skipping the post instead of reassigning it to the first available admin user is a cleaner solution. * fix: removed unused references from a past commit * fix: appeasing PHPCS * Bump versions to 3.6.3 (#1070) --------- Co-authored-by: Alec Geatches <[email protected]> Co-authored-by: Gary Jones <[email protected]> Co-authored-by: claudiulodro <[email protected]> Co-authored-by: Yoli Hodde <[email protected]> Co-authored-by: Eddie Carrasco <[email protected]>

eddiesshop requested review from rebeccahum and GaryJones August 26, 2023 02:29

eddiesshop linked an issue Aug 26, 2023 that may be closed by this pull request

post_author not updated properly if assigning a new WP user #903

Closed

Merge pull request #989 from Automattic/release/3.5.15

33ae3b0

eddiesshop requested a review from danielbachhuber August 29, 2023 16:32

danielbachhuber removed their request for review August 29, 2023 21:19

GaryJones removed the request for review from rebeccahum August 30, 2023 21:03

GaryJones added this to the 3.5.16 milestone Aug 30, 2023

GaryJones added Type: bug Status: needs investigation labels Aug 30, 2023

eddiesshop added 6 commits September 2, 2023 14:36

fix: preventing loss of fact that a guest author might also be a WP_User

92c6725

fix: attempting DB update only when $new_author is not empty.

017dc74

Also, returning the actual response from the DB, to make this call even more accurate in terms of what is actually happen at the DB layer.

fix: need to ensure pure WP_User is processed correctly as post_author.

a0635df

A pure WP_User (i.e. a WP_User that IS NOT linked to a Guest Author) needs to be handled specially.

fix: returning a plain WP_User if guest authors is not enabled.

b71ea29

I forgot to run tests on my previous commit. This satisfies the test Test_CoAuthors_Plus::test_get_coauthor_by_when_guest_authors_not_enabled which is expecting a WP_User when the plugin is not enabled.

GaryJones force-pushed the fix/missing_wp_user_type branch from 62393cb to b71ea29 Compare September 2, 2023 13:36

eddiesshop added 11 commits September 8, 2023 12:46

feat: adding additional tests for co-authors-plus.php functionality.

fbf2087

Merge branch 'main' into fix/missing_wp_user_type

756d9fc

Merge branch 'develop' into fix/missing_wp_user_type

0d55c46

fix: preventing loss of fact that a guest author might also be a WP_User

e64921e

fix: attempting DB update only when $new_author is not empty.

7ece2ab

Also, returning the actual response from the DB, to make this call even more accurate in terms of what is actually happen at the DB layer.

fix: need to ensure pure WP_User is processed correctly as post_author.

741c053

A pure WP_User (i.e. a WP_User that IS NOT linked to a Guest Author) needs to be handled specially.

fix: renaming user_login's for new authors introduced for new tests.

e7c7792

These user_login's were causing other tests to fail because you cannot create another user with the same user_login.

fix: removing use of assertObjectHasProperty

b6b959b

Older version of PHPUnit do not have this function available. Updating to workaround: `assertTrue( property_exists( $obj, 'prop' ) )`

fix: typo in function call

41006b3

GaryJones mentioned this pull request Sep 17, 2023

post_author not updated properly if assigning a new WP user #903

Closed

GaryJones previously requested changes Sep 17, 2023

View reviewed changes

eddiesshop added 8 commits October 14, 2023 10:31

Merge branch 'develop' into fix/missing_wp_user_type

1a2d06f

fix: using strict comparison instead of function call is_null

7e4bd8e

fix: using more descriptive assertion for array validation.

aacd37b

fix: using create_and_get post factory func, to avoid query call.

fc05f9d

fix: removing use of newly introduced is_wp_user property.

a0b808a

Relying instead on wp_user property which has already been used before.

fix: PHPCS fixes and added commentary/descriptions to docblocks.

e3a120a

fix: some small quick fixes for formatting and documentation

6afab35

Merge branch 'develop' into fix/missing_wp_user_type

719c15c

GaryJones modified the milestones: 3.6.1, 3.6.2 Apr 25, 2024

Merge branch 'develop' into fix/missing_wp_user_type

3c27322

eddiesshop mentioned this pull request Jul 2, 2024

Migrating from custom system, and not able to keep the order in authors. Wrong sorting. #1052

Open

eddiesshop added 8 commits July 2, 2024 17:58

Merge branch 'develop' into fix/missing_wp_user_type

175d8fe

fix: removing repetitive test.

de55e39

add: new assertion func that determines if an obj is not a WP_User class

8dd6d67

add: new assertion to help determine if a Post has the correct Authors

db9a6d7

add: new test solely for CoAuthorPlus::get_coauthor_by().

bbfc79a

By fully testing CoAuthorPlus::get_coauthor_by(), we can remove some repetitive assertions that don't directly relate to what's being tested.

fix: was passing string values when I should've been passing Author objs

312d519

fix: using a data provider for very similar tests

961ce40

Merge branch 'develop' into fix/missing_wp_user_type

d7e0274

leogermani removed the Status: needs investigation label Oct 9, 2024

leogermani assigned eddiesshop Oct 9, 2024

leogermani approved these changes Oct 9, 2024

View reviewed changes

leogermani merged commit fea7157 into develop Oct 9, 2024
6 checks passed

leogermani deleted the fix/missing_wp_user_type branch October 9, 2024 20:24

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix/missing wp user type #988

Fix/missing wp user type #988

eddiesshop commented Aug 26, 2023 •

edited by GaryJones

Loading

eddiesshop commented Aug 31, 2023

GaryJones commented Aug 31, 2023

GaryJones left a comment

GaryJones Sep 17, 2023

GaryJones Sep 17, 2023

GaryJones Sep 17, 2023

GaryJones Sep 17, 2023

eddiesshop Jul 2, 2024

GaryJones Sep 17, 2023

eddiesshop Jul 2, 2024


		$this->assertEquals( 1, $query->found_posts );
		$this->assertEquals( $this->author1->ID, $query->posts[0]->post_author );

Fix/missing wp user type #988

Fix/missing wp user type #988

Conversation

eddiesshop commented Aug 26, 2023 • edited by GaryJones Loading

Description

Deploy Notes

Steps to Test

eddiesshop commented Aug 31, 2023

GaryJones commented Aug 31, 2023

GaryJones left a comment

Choose a reason for hiding this comment

GaryJones Sep 17, 2023

Choose a reason for hiding this comment

GaryJones Sep 17, 2023

Choose a reason for hiding this comment

GaryJones Sep 17, 2023

Choose a reason for hiding this comment

GaryJones Sep 17, 2023

Choose a reason for hiding this comment

eddiesshop Jul 2, 2024

Choose a reason for hiding this comment

GaryJones Sep 17, 2023

Choose a reason for hiding this comment

eddiesshop Jul 2, 2024

Choose a reason for hiding this comment

eddiesshop commented Aug 26, 2023 •

edited by GaryJones

Loading