Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#56609 closed defect (bug) (fixed)

Handbook - links pointing to is_wp_error function

Reported by: dingo_d's profile dingo_d Owned by: peterwilsoncc's profile peterwilsoncc
Milestone: 6.1 Priority: normal
Severity: normal Version:
Component: General Keywords: needs-patch 2nd-opinion
Focuses: docs Cc:

Description

In the themes handbook: https://developer.wordpress.org/themes/functionality/post-formats/#adding-post-type-support

The links to register_post_type() function for instance (there are 17 others instances) points to the is_wp_error function (instead of the correctly linked function).

Not sure where the problem is, when I edit the page, the link block looks correct.

My guess is something with the syntax highlighting could have caused this?

Attachments (1)

code.png (140.0 KB) - added by dingo_d 2 years ago.

Download all attachments as: .zip

Change History (15)

@dingo_d
2 years ago

This ticket was mentioned in Slack in #docs by dingo_d. View the logs.


2 years ago

This ticket was mentioned in Slack in #meta by coffee2code. View the logs.


2 years ago

This ticket was mentioned in PR #3300 on WordPress/wordpress-develop by dd32.


2 years ago
#3

  • Keywords has-patch added; needs-patch removed

#4 @dd32
2 years ago

  • Keywords needs-patch added; has-patch removed

This is caused by [54234] in some way I believe (cc @peterwilsoncc)

wp> get_page_by_title( 'wp_insert_post', OBJECT, 'wp-parser-function' )->post_title;
string(11) "is_wp_error"

Last Query:
SELECT  wp_posts.ID
FROM wp_posts
WHERE 1=1  AND wp_posts.post_type = 'wp-parser-function' AND ((wporg_33_posts.post_status = 'publish' OR wp_posts.post_status = 'future' OR wp_posts.post_status = 'draft' OR wp_posts.post_status = 'pending' OR wp_posts.post_status = 'trash' OR wp_posts.post_status = 'auto-draft' OR wp_posts.post_status = 'inherit' OR wp_posts.post_status = 'private'))
ORDER BY wp_posts.ID ASC
LIMIT 0, 1

Called via WP_CLI\Shell\REPL->start, eval, get_page_by_title, WP_Query->__construct, WP_Query->query, WP_Query->get_posts, wpdb->get_col

(Note, I've slimmed the query, removing some plugin-related statuses)

Looks like post_title isn't a valid WP_Query field, but title is, so I'm not sure how the tests in #36905 succeeded. See https://github.com/WordPress/wordpress-develop/pull/3300

After the above PR, the query now includes the function name:

SELECT   wp_posts.ID
FROM wp_posts
WHERE 1=1  AND wp_posts.post_title = 'wp_insert_post' AND wp_posts.post_type = 'wp-parser-function' AND ((wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future'....
Last edited 2 years ago by dd32 (previous) (diff)

dd32 commented on PR #3300:


2 years ago
#5

Looking at https://core.trac.wordpress.org/changeset/54234 it seems there's no tests that cover the new functionality when there exist multiple of the post_type, so the result was always the same.

A unit test that adds two pages, and ensures that the correct page object is returned would be of benefit here.

This ticket was mentioned in Slack in #meta by dd32. View the logs.


2 years ago

peterwilsoncc commented on PR #3300:


2 years ago
#7

As discussed via Slack, I'm pushing a bunch of commits to this PR to get started on this.

I'm starting with some tests so have reverted the fix to get them failing against the code base as is.

peterwilsoncc commented on PR #3300:


2 years ago
#8

Looking at https://core.trac.wordpress.org/changeset/54234 it seems there's no tests that cover the new functionality when there exist multiple of the post_type, so the result was always the same.

I've added some shared fixtures to prepopulate the post table with various post types used within the tests.

A unit test that adds two pages, and ensures that the correct page object is returned would be of benefit here.

test_should_match_oldest_published_date_when_titles_match() should serve this purpose.

Stripped of the post statuses for convenience, the resulting queries after these changes are

{{{sql
SELECT wptests_posts.*
FROM wptests_posts
WHERE 1=1 AND wptests_posts.post_title = 'foo' AND wptests_posts.post_type = 'page'
ORDER BY wptests_posts.post_date ASC, wptests_posts.ID ASC
LIMIT 0, 1
}}}

TimothyBJacobs commented on PR #3300:


2 years ago
#9

Patch and tests look good to me. Discussed with @peterwilsoncc about the change to the orderby property. It is odd that it looks like the original get_page_by_path since the query doesn't seem to specify any ordering. However it looks like these new tests pass on 6.0, so we should be good to go.

peterwilsoncc commented on PR #3300:


2 years ago
#10

However it looks like these new tests pass on 6.0, so we should be good to go.

To document how I tested:

  • removed the caching checks in the tests
  • replaced the get_page_by_title() with the 6.0 version
  • phpunit --group 36905
  • Swapped the order of insertion of old page in test_should_match_oldest_published_date_when_titles_match()
  • phpunit --group 36905 ✅ (still with 6.0 version of function)

#11 @peterwilsoncc
2 years ago

  • Owner set to peterwilsoncc
  • Resolution set to fixed
  • Status changed from new to closed

In 54271:

Posts, Post Types: Fix WP_Query parameter used by get_page_by_title().

Fixes the call to WP_Query within get_page_by_title() by using the correct title parameter, title.

Modify the orderby parameter to prioritize the oldest published date over the smallest post ID. This ensures the behaviour matches that of the previous version of get_page_by_title().

The tests have been modified to include a populated post table to ensure the posts returned are matched by design rather than coincidence.

Follow up to [54234].

Props dd32, timothyblynjacobs, peterwilsoncc.
Fixes #56609.
See #36905.

peterwilsoncc commented on PR #3300:


2 years ago
#12

Committed in https://core.trac.wordpress.org/changeset/54271 / 6c6a6747a02d7f196cfc2f8dbe64181caccbee93

#13 @desrosj
2 years ago

  • Milestone Awaiting Review deleted

#14 @desrosj
2 years ago

  • Milestone set to 6.1
Note: See TracTickets for help on using tickets.