Skip Navigation

[Escalated to 2nd Tier] Toolset Image Field not compatible with WP's new image scaling feature

This support ticket is created 2 years, 2 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

This topic contains 5 replies, has 2 voices.

Last updated by Waqar 2 years, 2 months ago.

Assisted by: Waqar.

Author
Posts
#2447505

WP has a new image scaling feature added in WP 5.3 (https://developer.wordpress.org/reference/hooks/big_image_size_threshold/).

This feature makes that when you upload images to the media library above a certain size (Default 2560), WP will automatically scale that image, and rename the asset just uploaded by appending a

-scaled

suffix.
Now, when you use these images in a Toolset Image Custom Field, the field will (after either uploading image in it directly, or inserting one already uploaded), use the "original" name (thus without "-scaled" suffix).

This, per se, is not an issue:
when using the shortcode to display the image of the Toolset field, the image will still display. But, not the "-scaled" version, instead, the full original image version.
That would be OK, however, the issue goes deeper as when you use

attachment_url_to_postid

to get the ID of that image from the URL saved in the Toolset Image Field, you will get

false

returned.

That, is a real issue, because you cannot at all change the URL saved in the Toolset Image field. Even if manually editing it to use the suffixed "-scaled" image, it will immediately revert to the original image attachment url.

Steps to replicate:
1. Create an image Field with Toolset.
2. Upload a big image to this field (for example hidden link)
3. Insert that Image to your new Image Field
4. Try to convert that value saved in the field to the Attachment ID using this code:

attachment_url_to_postid( types_render_field( "image-field-slug" ) );

You will get

false

returned.
The right value returned however would be the ID of the attachment, which is the case as long you use the real attachment URL (which will have a "-scaled" suffixed).

So there are 2 problems surging from this bug:
1. The scaled images are not used
2. The full (original) image URL (attachment URL) produces false on attachment_url_to_postid

This was tested and confirmed on a clean fresh WP install with Toolset Types only.

#2447831

Hi Beda,

Great to hear from you.

I did some digging and found that there is an open WordPress ticket for this issue already:
https://core.trac.wordpress.org/ticket/51058

So based on this, this is something that will need to be addressed at the WordPress core level.

Meanwhile, anyone trying to use the "attachment_url_to_postid" function can include a condition to check, that if the function returns false, then also check for the image URL from the image custom field with the '-scaled' suffix, appended.

I hope this helps.

regards,
Waqar

#2449153

Hi Waqar, thanks for digging up those tickets, indeed, that issue seems due to WP

However, Toolset saves the wrong image. Notice how - when uploading an image - WP shows the "-scaled" as the attachment URL in the very Image editor/media library? That is what we insert using the Toolset Field. We are not inserting the original image, we clearly insert the "-scaled". Moreover, when we manually edit that field that value should persist, and not just revert back to something else.

Thus, while this is a WP bug when speaking about the attachment_url_to_postid not returning a valid ID, it is also a Toolset bug when we speak about what image is actually saved.
All that Toolset would need to do to resolve this issue is actually pick the attachment URL that is used by WP when inserting the image, without attempting to do background magic and changing that value on save.

I would understand this behaviour if the attachment URL would actually be the original, but it is not, as you can see when inserting/adding/editing the image using WP Media Button/library.

#2449519

Thanks for writing back.

To confirm if I understand your recommendation correctly, do you suggest that:

A). Toolset image field should always store the image URL with the "-scaled" suffix, (whenever applicable)

OR

B). Toolset image field should only store the image URL with the "-scaled" suffix, whenever a user selects an already uploaded image from the media library or specifically types/pastes in the URL with the "-scaled" suffix

#2449883

It is not a suggestion, but the discernible expected behaviour:
1. I insert an image using a Toolset Image Field using the "add image" button, which pops up the media browser of WP.
2. If WP as the attachment URL has XY I want to see XY in the Toolset field too, not YW. The attachment URL is clearly visible in the Media "Edit" thingy that opens when you insert an image with Toolset...
3. If I edit that Toolset field manually to YW after insertion, I want to see YW after saving the field, not XY, since it is an editable text input.

---

Waqar, something else, I stumbled over https://toolset.com/forums/topic/woocommerce-hidden-products-are-visible/ and https://toolset.com/forums/topic/not-show-products-with-catalog-visibility-hidden/.
Both are wrong. Probably because time passed and WC change how it handles hidden products, etc, but fact is, with Toolset WPA you will not be able to create a shop where the "hidden" product is actually hidden. It will always appear in the shop, product category archive or else.
The only way to hide the hidden products is either with WPV Conditional (wrong because the count will still consider those products) or custom code, pasted below an example. Maybe you can update those tickets? I cannot add comments there.

add_action( 'pre_get_posts', 'remove_hidden_products', 999 );
function remove_hidden_products( $query ) {

	if ( $query->is_main_query()
		&& ! is_admin()
		&& ( $query->is_search() 
		   	|| $query->get( 'post_type' ) === 'product'
			|| $query->is_tax( 'product_cat' )
		   )
	   ) {

		$tax_query = $query->get( 'tax_query', array() );
		$tax_query[] = array(
            'taxonomy' => 'product_visibility',
            'field'    => 'slug',
            'terms'    => array( 'exclude-from-catalog', 'exclude-from-search' ),
            'operator' => 'NOT IN',
        );

        $query->set('tax_query', $tax_query);

	}

}

Those tickets are relatively recent, and I am pretty sure others will appreciate having a proper working solution to the problem.

Thanks!

#2451183

I have shared your feedback on the handling of the big images by the Toolset image field with the concerned team. I'll keep you updated, as I'll hear back from them.

And thank you for sharing the code snippet for excluding the 'hidden' products from the archives. I've added a note about it, in both tickets, that you mentioned.