Open cgrycki opened 1 year ago
I believe a few additional changes will be necessary before this is ready for review. Hope to have those tested and committed soon.
I identified an issue last week that I had initially thought may have been a result of the change in this PR. After further investigation, I determined that the issue was unrelated to the changes in this PR and arose from an update to a different WordPress plugin that introduced a setting impacting when the transition_post_status action was triggered. The issue was resolved by configuring that setting in the other plugin. The code from this PR is working as expected in our production environment. I will mark this as ready for review.
When an invalidation is submitted for post type that does not have an archive page, the invalidation paths submitted may include the path "://*". This results in a 400 bad request status from the CloudFront API. The issue can be traced to the parse_url function in classes/WP/Post.php. The function will accept a null or empty string for the URL. Doing so will cause the function to return the string "://". Possibly related to #107.
Since the calling function get_the_post_type_archive_links() is already written to handle a situation where parse_url returns an instance of WP_Error, I have updated parse_url to return a WP_Error object when the given url is empty or null. That appears to be the intended behavior from the existing code. As a result of this change, cache invalidations for post types without an archive page do not include the invalid path in the submission to CloudFront.
A unit test has been added to test/WP/Post_Test.php to validate that parse_url returns an instance of the WP_Error class when given an empty string.