Overloaded `Relationship` properties can't be checked with `isset`

[acrobertson]

Bug Description

The majority of properties on the Cloudinary\Relate\Relationship class are undeclared and accessible through the magic __get() method.

If you check for the existence of one of these properties, e.g., public_id, using isset(), it will return false, even if it is in fact set.

This is because there is no magic __isset() method in the class.

This is impacting me because I am building a Timber theme where I've extended its Attachment class with a cloudinary_relationship method that calls the static \Cloudinary\Relate\Relationship::get_relationship() method to make that relationship data available to all attachment posts.

But in a Twig template, only the declared properties (e.g., post_id, save_on_shutdown, etc.) are accessibile. Using dot notation to access cloudinary_relationship.public_id returns null. This is because under the hood Twig is calling isset() (and by extension __isset()) to verify the existence of the property. Without the magic __isset() method, it returns false, and I'm not able to access any of the overloaded properties within Twig templates.

Expected Behaviour

The Cloudinary\Relate\Relationship class should include an __isset() method.

Steps to reproduce

Assumptions:

1. Cloudinary plugin is active
2. An attachment post with id 92 exists
3. Attachment 92 has been synced to Cloudinary

$post_id = 92;
$cloudinary_relationship = \Cloudinary\Relate\Relationship::get_relationship($post_id);

echo $cloudinary_relationship->public_id;
// Prints `wordpress_assets/title-of-image`
// So we know this property is set.

isset($cloudinary_relationship->public_id);
// Returns `false`.
// It should return `true`

I have confirmed that repeating these steps with an __isset() method returns true as expected.

I don't see any contribution guidelines in this repo, but since it's such a straightforward update, I'll go ahead and follow this issue up with a PR for you to review in case you are open to contributions.

Additional context

• WordPress version: 6.8.1
• Plugin version: 3.2.7
• Gutenberg plugin version (if applicable): N/A
• PHP version: 8.2
• Plugin settings: N/A

[Vdeub-cloudinary]

Hi @acrobertson,
Thanks for raising this issue.

Could you please share a bit more about your use case and what you are trying to achieve?

I'll let the team know about your PR and let them decide the next step.
Best,
Loic

[acrobertson]

@Vdeub-cloudinary, Sure thing!

In case you’re not familiar, Timber is a package for building WordPress themes with the Twig templating engine. It uses an MVC pattern, with PHP files acting as controllers that pass data to Twig views.

In my case, I'm passing a \Cloudinary\Relate\Relationship object into a Twig template* and finding that none of the dynamic properties, like public_id, are accessible there.

Here’s a very simplified example with some code:

// single.php

use Timber\Timber;

$attachment_post_id = 92;
$cloudinary_relationship = \Cloudinary\Relate\Relationship::get_relationship($attachment_post_id);

var_dump($cloudinary_relationship->public_id);
// Dumps ‘wordpress_assets/filename.mp4'

$context = new Timber::Context();
$context['cloudinary_relationship’] = $cloudinary_relationship;

Timber::render(‘page.twig’, $context);

{# single.twig #}

{{ dump(cloudinary_relationship.asset_type) }}
{# Dumps 'video' #}
{# This property is explicitly declared in the class, so we can access it #}

{{ dump(cloudinary_relationship.public_id) }}
{# Dumps `null` #}
{# Twig can't verify the existence of the dynamic property #}

You can read more about Twig's steps for resolving object properties using dot notation.

Note the second step here [emphasis mine]:

• check if user is a PHP array or a ArrayObject/ArrayAccess object and name a valid element;
• if not, and if user is a PHP object, check that name is a valid property;

In their recipes, they have an entry on using dynamic properties:

When Twig encounters a variable like article.title, it tries to find a title public property in the article object.

It also works if the property does not exist but is rather defined dynamically thanks to the magic __get() method; you need to also implement the __isset() magic method [...]

I confirmed that the change in my PR makes the dynamic properties available within Twig templates. It also makes the isset() behavior more intuitive within PHP for these properties, but it's especially useful for this Twig use case.

Please let me know if you have any additional questions!

---

* If you're wondering why I'm bothering to access this data at all, the short version is that I needed more control over the video player. I installed the Cloudinary player package and needed to expose the video attachment's Cloudinary data (most importantly, the public_id) as HTML data attributes to access them from JavaScript. So I queried for the relationship, passed it to the template, and that's when I ran into this issue.

Another simplified example:

<video class="cld-video-player" src="{{ attachment.src }}" data-cld-public-id="{{ attachment.cloudinary_relationship.public_id }}" />
{# Bug: `data-cld-public-id` is `null`, as explained above #}

I'm sure there's a Feature Request or two that I could pull out of there and share separately (exposing video player styles, allowing video settings to be applied per-video rather than globally, etc.), but in the meantime, I thought I'd share this issue and help to resolve it.

The obvious workaround was to access $cloudinary_relationship->public_id in the PHP file and pass it directly to the template as cloudinary_public_id. But this isn't ideal, since it has to be done for every other property that needs to be accessed. Passing the whole object would be much more straightforward and is enabled by the addition of the __isset() method. And if it saves one more person the trouble of debugging these mysterious missing properties, I'd consider it worthwhile!

So there's one layer deeper w/r/t my use case. Again, please let me know if you need anything else from me in explaining this issue!

[aatanasovdev]

@acrobertson, Thank you for explaining the issue in detail and providing information regarding why this change is needed. I agree, it will save a lot of time in debugging if someone uses the plugin classes in custom solutions.

The PR has been approved, and the changes will be available in the next Cloudinary plugin version. I'll close the issue after the release.