Develop In Situ PHPUnit tests for WordPress TRAC #13459

[bobbingwide]

In https://herbmiller.me/requirements-for-permalink-postname/ I've documented my requirements for a permalink structure of /%postname%/.

The above (perma)link applies to both a page and a post.
With the current implementation of WordPress, the page trumps the post, but you can get to read the post since I've fetched the post's contents into the page using a shortcode which accesses the post by its post ID.

This trumping is a bug that was originally reported in #13459 Conflict between post and page slugs/permalinks when permalink setting is set to /%postname%/.

The dupes plugin may eventually include a workaround to the current WordPress issue. In the meantime, we need some automatic tests for a variety of different combinations of permalink structure, post status and CPT combinations.

Requirements

Develop some automated tests for WordPress permalink functionality.

These need to reflect real usage and user's expectations. eg

• A post and a page with the same title.
• A post with an image linked to the attachment page.

This first example fails when the user clicks on a link to the post but the page is displayed instead of the post. The second fails when clicking on the image redisplays the post. Expected result: it should lead to the attachment page.

The tests should also test scenarios which currently work. eg.

• Two posts with the same title.
• Two pages with the same title.
• Two pages with different ancestors with the same title.

More advanced tests would cover:

• other permalink structures,
• different post statuses for the trumping post
• other combinations of Custom Post Type, pages, posts and attachments
• Other forms of link that looks like they should work but don't currently eg https://example.com/?p=1234

The underlying requirement is, if a user is displayed some content with a link to view more of that content then, when the link is clicked, that content should be displayed. It should not result in different content, a 404 or other unexpected result.

Proposed solution

• [ ] Develop PHPUnit test cases for the above
• [ ] Extend original test cases for TRAC 13459 to include requesting the content for the generated permalink.
• [ ] Support in situ testing as used for my other plugins

[bobbingwide]

When run using pu - to invoke PHPUnit under oik-batch for in situ testing - the current output is a below.

C:\apache\htdocs\phpLibraries\phpunit\phpunit-9.5.5.phar
Searching for wp-config.php in directories leading to: C:\apache\htdocs\cwiccer\wp-content\plugins\dupes
Found wp-config.php in: C:\apache\htdocs\cwiccer/
oik-wp running WordPress 5.9.2
C:\apache\htdocs\wordpress\wp-content\plugins\dupes
cli
Using wordpress-develop-tests plugin
PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.0.2
Configuration: C:\apache\htdocs\wordpress\wp-content\plugins\dupes\phpunit.xml.dist

.F                                                                  2 / 2 (100%)

Time: 00:04.103, Memory: 50.00 MB

There was 1 failure:

1) Tests_issue_13459::test_duplicate_page_post
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'<p class="duplicate-title-trac-13459">duplicate title TRAC 13459:post:publish:2758</p>'
+'<p class="duplicate-title-trac-13459">duplicate title TRAC 13459:page:publish:2756</p>'

C:\apache\htdocs\wordpress\wp-content\plugins\dupes\tests\test-issue-13459.php:194
C:\apache\htdocs\wordpress\wp-content\plugins\dupes\tests\test-issue-13459.php:249

FAILURES!
Tests: 2, Assertions: 30, Failures: 1.
<!--PHP version:8.0.2
--><!--PHP functions:1271
--><!--User functions:3342
--><!--Classes:1328
--><!--Plugins:1
--><!--Files:1505
--><!--Registered widgets:45
--><!--Post types:14
--><!--Taxonomies:7
--><!--Queries:316
--><!--Query time:0.42538166046143
--><!--Trace file:C:/apache/htdocs/cwiccer/bwtrace/bwtrace.cli
--><!--Trace records:89

• Test 1 - test_duplicate_post_post worked
• Test 2 - test_duplicate_page_post failed since both the post and the page have the same permalink. The page trumps the post.

The failure was not because the post's permalink was not unique, but because, from the point of view of the requester, the wrong post was returned.

[bobbingwide]

• I've developed some in situ tests.
• These run in different environments with different initial permalink structures ( s.b/cwiccer and s.b/wordpress ).
• They consistently fail where they're supposed to.
• I now want to extend the tests to demonstrate failure to fetch the duplicated post using a variety of request forms that I believe should be supported.