don't guard against non-"attachment" post-type

[drzraf]

This code-path can't be override (contrary to checks done by the Timmy\Image constructor. Be it for usage with custom-post-type or subclassing attachment, or any other plugin edge-case, this check would be better left to a place it can be skipped/made optional.

[gchtr]

@drzraf I think I see what your concern is.

But I think we still need some kind of check whether it’s a post. And I didn’t want to introduce a full factory pattern yet. So my question is. Would a check for a post work, as we do it in Timber?

$wp_post = \get_post($attachment);

if (!$wp_post) {
    return null;
}

[drzraf]

For my use-case, yes, it would be fine: Ensuring the object is present in the database is one thing.

My problem is about assuming that the object to be used is going to have post_type == "attachment" (instead of, eg, a duplicated-attachment, attachment-revision, remote-attachment-mirrored, ... or whatever strange things plugins could do using custom post types)

[gchtr]

Alright, I’m totally fine with not checking for the attachment post type explicitly. But there’s some functionality in Timmy that relies on an object being a WordPress post. So I added that check in #85.

This is now released in https://github.com/mindkomm/timmy/releases/tag/v2.1.0.