I have a function whose job is to look through a string that is a post's content and find certain pieces:

public static function findInsidePostContent( $post = Null )

    //post_content comes from a WP_Post object.
    $post_blocks = \parse_blocks( $post->post_content );
    //Look inside, do some things.


The function has an absolute truth that we can always rely on: it only and solely works with a WP_Post object.

But, naturally, since the parameter is Null, there is a clear contradiction here, so, let's try to solve it by adding a specific line right at the start of the function:

$post = Utils::getPostObject( $post ); if( \is_wp_error( $post ) ) return $post;

Great, that function is always supposed to return a WP_Post object, unless something wrong happened.

But what we just did was heavily couple two seemingly unconnected pieces of code and, usually, that's bad. We also hid a dependency. But what if we can predict that in all the cases, you will always work with a WP_Post object? You'll always have to work resolve that WP_Post object somewhere before:

$post = Utils::getPostObject( 21 );
Utils::findInsidePostContent( '', [], $post );

This "call path" will never, ever change.

Wouldn't the coupling be justified?

  • 2
    If findInsidePostContent must always receive a WP_Post object, why does the $post parameter have a Null default value? Apr 30, 2020 at 12:49
  • @BartvanIngenSchenau Exactly the point of the question - to ease the process of using findInsidePostContent by auto-resolving that WP_Post object inside. Apr 30, 2020 at 12:52

1 Answer 1


Lets first see if calling the function getPostObject is justified at all, independent of the apparent coupling it produces.

The answer here depends entirely on what promises findInsidePostContent makes towards its callers. If findInsidePostContent has a precondition that it must be called with an WP_Post object, then inside the function there should at most be a check that the $post parameter really is a WP_Post object, but certainly no attempts to turn it into one.
On the other hand, if findInsidePostContent is supposed to be able to accept any argument that can be resolved into a WP_Post object, then the call to getPostObject is very legitimate.

To answer the question on coupling, I will assume that the call is legitimate.

While getPostObject should be blissfully unaware of the existence of findInsidePostContent, the latter function needs the services of getPostObject to do its job, because the post's content can only be accessed after it has been resolved/converted into a WP_Post object, which is exactly the job of getPostObject.

This means that the coupling is just as necessary as the coupling with \parse_blocks and the other functions that findIndidePostContent calls.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.