Skip Navigation

[Resolved] Types Image Auomatic Sizing Issue with Types 1.5.3 (Reopening Ticket #184411)

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.

This topic contains 8 replies, has 2 voices.

Last updated by Adriano 7 years, 8 months ago.

Assigned support staff: Adriano.


Reopening the ticket which was inadvertently closed.

The issue continues to require assistance. I have provided Adriano with the requested log in information to a restored backup of the production website, which demonstrates the same issue as the production site with re-sized images originally added via Gravity forms. The address of the restored backup is: hidden link

Scott Simpson


Hi Scott,

I'm checking it for you.


Hi Scott,

Is it solved? I can not see the problematic images anymore there: hidden link


The issue still exists:

First sample listing: hidden link - The image link is to an incorrect image address and hence the image is broken. This is an image that needs to be re-sized . . . but isn't being re-sized properly.

If you log into the demo site, you will see that the "Test Listing One Member listing has the correct address for the image that was uploaded using Gravity forms: hidden link

However, the listing on the front end ends up with a DEFECTIVE address: hidden link

I believe a portion of the address that needs to be created and saved when the image is re-sized is apparently being lost in the image re-sizing process.

Second sample listing: hidden link - This image is fine, but that is because the image doesn't need to be re-sized.

The address for this image is still based on where Gravity forms initially stored it: hidden link

To recap, when an image needs to be re-sized, the code that handles that isn't working properly. I don't know if the re-size is processed once or happens "on the fly" each time the content is loaded to be displayed.

I hope that helps. Call me if you have any questions at 248.862.7220.


To help in the diagnosis, I looked and confirmed that image for "Test Listing One" was properly re-sized down to 400 x 200 px, which I now gather happened once on January 8, 2014, when it was first uploaded and the listing was published (I don't know which of those two events triggers the re-size process). The correct re-sized image address is: hidden link

So, Types knows where the original 600 x 300 pixel image is stored (this is the address shown in the member listing content itself), it did re-size it properly, but somewhere along the way, the address for the re-sized image has been distorted by "tossing out" the portion of the address that relates to where the image is stored within the Gravity forms folder within the uploads folder: . . . gravity_forms/17-26a7ff8ba9468bdedcb98070f13ae73e/ . . .

Additional note: To manually correct this problem when I first discovered it on the production site, I was able to find the original images based on the address stored in the member listing custom field, download the image manually and then manually reattach each image individually to each listing by uploading then them again. These images do display properly. However, these images are stored directly in WP content/uploads directory, and not in the Gravity forms directory within the uploads directory. This contained the problem for me with the client, but there are three issues with the approach: 1) It is a secondary manual process, 2) I end up with the images, full size and re-sized stored in two locations, 3) I'm not getting the full value of the linkage with Gravity forms that worked so nicely previously.

One more reminder: I know there is a very new update to Gravity forms available (now 1.8.1). I haven't upgraded to that level. I don't know if that could possibly change where/how Gravity forms stores the uploaded member listing images in the future, which could possibly have an effect on how the Types code needs to behave going forward. We can evaluate that at some point if you'd like, but I can't imagine that would address the issue I'm having with existing, previously uploaded larger images that need to be re-sized.

Scott Simpson


Dear Scott,

Ok, thank you for all details. I will need to ask our Types developer to get some advise, will back soon. Thank you for your understanding.


Dear Scott,

I've talked with our Types developer. It's problem with upload dir and normalization file name. Types started using only date structured uploads directory, example: wp-content/uploads/2014/01

This change was made to make it work right with WPTotalCache plugin (CDN storage). There are some fixes in trunk for image storing, but we think it won't be able to use wp-content/uploads/gravity_forms/ directory.

So I've just opened a new item on our to do list to check this issue and fix in a next release. Thank you for your understanding.

Please let me know if you are satisfied with my answer and if I can help you with any other questions you might have.



My appreciation to you and the Types developer for looking into this. I understand your feedback.

Some additional feedback to share that you may find helpful as you consider a fix for this issue in the future:

1. Since I had nothing to lose and for your information, I updated the development site to Gravity forms 1.8.1 and then uploaded a new listing via Gravity forms. As I expected, the "behavior" is still the same with "broken" links for re-sized images. Gravity forms is still using the unique directory to store images which Types also uses to store the re-sized images. However, as we now know, Types doesn't use that address to fetch the images when the listings are displayed.

2. Now that I know where the re-sized images are being stored, I am able to go in and manually edit the image address in the custom post and point it to the re-sized image rather than the original image file (only necessary for re-sized images). If I then re-save the post, Types now displays the re-sized image. This is a a better "work around" than downloading the original image and then uploading it again to WordPress, as it avoids having the images (original and re-sized) stored in two locations.

3. Although Types doesn't control this, NOT having the images that are uploaded via Gravity Forms stored in the main Media Library is something that I prefer. It helps to keep the clutter down in the Media Library and avoid that being a possible distraction for my client.

4. I'd suggest you check for any other concern reports that might be running into this issue too. A succinct summary of this issue for those using Gravity forms might help others who could be experiencing "broken image links" but don't know what is going on, particularly if all of their images are being re-sized.

5. I'd also suggest that you touch base with the developers of Gravity Forms as you consider options to address this. Working together, you might be able to coordinate a fix that will allow the re-sizing feature to work again in the future. The ability of Gravity Forms and Types to work together is something I really appreciate!

At this point, I'll make the issue "resolved" . . . although a better description would be "understood and contained".

Sincerely, thank you again for your time and your help!!!

Scott Simpson


Good, you are welcome.