[Resolved] Debug error in wp-admin relating to images (Types 3.3)

[Author]

Posts

[julieP]

Since upgrading to WordPress 5.2 and Types 3.3, I'm seeing this error in my debug log and displaying in wp-admin on "child" posts for the related posts that contain images. The error is generated for each image in the post but the content doesn't vary, it's always:-

Notice: Trying to get property of non-object in /home/XXX/public_html/wp-content/plugins/types/vendor/toolset/types/embedded/includes/fields/image.php on line 1273

The images are displayed correctly in wp-admin and on frontend. Not sure if this is relevant but developer tools shows the URL for the image in wp-admin as the main one not the thumbnail even though the thumbnail exists.

I've also noticed that whilst post relationships don't seem to have been removed or changed, when I view the parent post in wp-admin, I'm only seeing the post title and no other field content from the child post whereas when I visit the child post, the field content from the parent post IS displayed.

Can you check if this issue can be replicated your end please?

Also, when I visited Toolset settings to get debug info, this is showing at the top of the page:-

Notice: Undefined property: stdClass::$rules in /home/XXX/public_html/wp-content/plugins/types-access/application/controllers/filters/backend_filters.php on line 330

[Nigel]

Hi Julie

Starting with the second one first, where the child fields are missing when on a parent post edit screen. You can customise which fields appear there with the button that is a cog icon. I found on my site that no fields were selected by default, but that I could choose to display them with that cog.

Now, the other two problems I cannot reproduce.

Have I understood the first correctly?

You have a parent-child relationship. The parent post has image fields (a repeating image field?). When editing a child post, where you can see the parent posts in the relationship metabox, this generates a warning in the debug.log.

I don't see that.

You say that the img URL points to the full sized image not the thumbnail. In my screenshot you can see the src points to the thumbnail, although there is a data-full-src attribute that points to the original full-sized image. You see the src itself pointing to the full-sized image?

I'm probably going to need a copy of your site to try and see the warnings, but let's clarify that I've understood the set-up correctly, first.

[julieP]

Hi Nigel

Thanks for mentioning the cog/settings option - I've not really noticed it to be honest and all my fields from related posts show by default but I don't now believe there's a problem with this bit.

Yes, you have understood correctly and the image field is not a repeating one.

Since you've not been able to reproduce the problem, I've done some comprehensive testing this morning. Here's what I found:-

Wordpress 5.1.1 + Types 3.2.7 = no errors
Wordpress 5.2. + Types 3.2.7 = no errors
Wordpress 5.1.1 + Types 3.3 = errors
Wordpress 5.2 + Types 3.3 = errors

so its to do with Types 3.3 not WordPress 5.2.

I've re-installed my 'pure' single (as opposed to multi site) test site, upgraded everything to the latest and implemented only the absolute basics required to replicate a parent post with image field & child post with just post title. My uploads are not organised by year/month. I'm using two hooks on my main dev site which rename the image and delete the 'attachment' pages created by WordPress. The renaming hook isn't causing a problem but when the attachment pages are deleted (whether the images have been renamed or not), the errors appear.

You may not agree with my approach here but attachment pages won't add anything for this site and I don't want them!! Any suggestions (checking and deleting the content from my debug log all the time would be a real pain in the ****)? Thanks

[Nigel]

Can you share the code with me you are using for deleting the attachment pages?

[julieP]

add_action('cred_submit_complete', 'ts1_after_save_data_form_23',10,2);
function ts1_after_save_data_form_23($post_id, $form_data) {
    
    global $wpdb;
	
    if ($form_data['id']==23) {
        
        $user_id = get_current_user_id();
        $typepost = 'attachment';
        
        $myquery = $wpdb->prepare("
        		 DELETE posts,pm
				 FROM {$wpdb->prefix}posts posts
				 LEFT JOIN {$wpdb->prefix}postmeta pm ON pm.post_id = posts.ID
				 WHERE post_author = %d
				 AND post_type = %s
				 ",
				 $user_id, $typepost
				 );
				 
		$wpdb->query($myquery);
    }
}

[Nigel]

OK, that explains a lot.

Adding image fields, whether in the backend or via a frontend form, is essentially the same as adding a featured image or inserting inline images within the content of the post, and involves WordPress creating an attachment post (i.e. a row in wp_posts) corresponding to that image.

It's clear looking at some of the code generating the warnings that Types expects to find these attachment posts, and meaning that removing them will result in unexpected behaviour, namely generating PHP warnings in this case.

I don't have any advice to offer, I simply don't think you can remove those attachment posts, and if you do, well, it means dealing with the consequences.

[julieP]

There haven't been consequences in deleting attachment pages with previous versions of Types. What purpose is served by checking that an attachment page exists as of the current version?

[Nigel]

I can't answer that, but I can say that the error-handling in our code should fail silently in such a scenario.

I've been able to reproduce the warning with Types 3.3 after manually deleting the attachment posts and its post meta, and so I'm passing the details on to the developer to review.

I'll let you know their feedback.

[julieP]

I appreciate that thank you.

It's well documented that website owners either aren't aware of attachment pages or don't really know what to do with them and that they are low value where SEO is concerned. At best the trend seems to be to redirect attachment pages to the parent so they're not indexed. What we can't get away from (if we don't delete them) is a waste of database resource and time in managing them when images are removed or changed. The latter is particularly true for sites where visitors upload images.

Deleting attachment pages hasn't been an issue to date & the current code makes an unfair assumption. I'll leave it in your capable hands to put forward my case!

[Nigel]

Hi Julie

We have released Types 3.3.1 which should fix this, could you please update and verify?

Thanks

[julieP]

Hi Nigel

That's excellent news; I've upgraded & tested and can confirm the errors are no longer appearing; I'm a happy bunny! Thank you