I am trying to:
Display images stored in a custom post field on my homepage. The url in the custom post field is confirmed HTTPS.
Link to a page where the issue can be seen:
Homepage, in the "testimonial slider". Some circular portraits are returned with HTTPS and some with HTTP. The use of firebug of chrome dev extension on the network tab shows this issue very well.
I expected to see:
Since all portraits are stored as hidden link in the image custom post field, I'm expected the src= of the img tag to always be https.
Instead, I got:
Some portraits are returned with http, breaking the ssl of the webpage.
Hi, please try these troubleshooting steps to see if the cross-protocol URLs are updated:
- Go to Toolset > Settings > Custom Content and clear the image caches by clicking both of the top buttons. Test again.
- Check both checkboxes in this same panel, save, and test again.
- Disable caching on this View. If the View is inserted into a template or post using a shortcode, you can add the cached="off" parameter like this:
[wpv-view name="your-view-slug" cached="off"]
Let me know if any of these tests resolved the issue and we can go from there.
Hi,
I have performed the requested operations, but the problem persist.
Originally, the view was displayed as a widget. I did not find how to pass cached=off for widget-displayed views, so I create a textarea for this. The problem is still there.
I also tried on the test site to remove and then re add the circular portrait with no luck.
What would be the next step?
Thanks
Francois
May I log in here or on the test site and take a look in the wp-admin area? I would like to see how this View is configured. Private reply fields are available here.
Sorry when I try to log in with these credentials it says I'm using the wrong password. I copied and pasted a couple of times to be sure but I'm getting the same results. Can you check? I will activate private reply fields again.
Okay thanks. With your permission, I would like to create a clone of your site so I can escalate this issue to my 2nd tier support team. We've had a couple of reports of image path issues after updating to Types 3.0.1, and I would like to gather your information with the other information so our developers can work on a comprehensive solution. If you approve, I will install the Duplicator plugin and create a site clone. Let me know if it's okay and I will get started.
On your dev site, I was able to create a clone using Duplicator. However, it's quite confusing because the post and attachment guids are wildly inconsistent. I can see post guids from several different domains, some on https and others not. Some are IP addresses or localhosts, others have www, others do not have www. Some are dev., some are www-dev., some are blake.w***t.ca, etc. So I'm not clear how much of this is just the fact that dev is development, and how much of this is a true representation from the production site. Do you have any additional information about why these domain guids are all different? Are they all consistent in the production database? Is it possible for you to provide a database SQL dump directly from production?
Hi Christian,
Best practice is to not update the GUID when migrating a website. When an "object" is created when running the website on let's say hidden link, the GUID will be using that URL.
The point is that this column is only being used to refer uniquely to a specific post. That's why I never update it when migrating from one instance to another. It could really be any string that is guaranteed to be unique.
I always use this when move my site from environments
# Search and replace but skip one column
$ wp search-replace 'hidden link' 'hidden link' --skip-columns=guid
https://developer.wordpress.org/cli/commands/search-replace/
To my knowledge GUID should not be used for anything else than a unique identifier. If this field end up being used to resolve ressources location, there is a problem with the code.
The dev site is a copy of the production environment, and was loaded on there about a month ago. These GUID will also be present in prod. Both sites have been upgraded with newer plugin version since then. They are approximately the same in terms of software, and both exhibit the problem described in this thread.
I hope this makes sense.
Thanks
François
Okay thanks for the extra information. I'm escalating this to my 2nd tier support team for further investigation, since it appears that the image URL is cached somehow and we are unable to clear it. I will keep you posted as I receive additional information.
Hi Christian,
I loaded a fresh version of prod on my server to perform a full migration to the new relationships model since the legacy model was giving me too much trouble.
Among other things, I was able to fix the slider problem by :
- Deleting the picture from the psychologist custom post image field
- Deleting the picture from the media library
- Re-adding the picture in the media library
- Re-adding the picture on the custom field image field
I can't explain why the image was carrying wrong information. The same library image was displaying properly (with https) on the archive page but not in the slider. Maybe deleting the image flushed the cache somehow.
François
Okay thank you for the additional information. I will pass this along to my 2nd tier support team so they can take it into consideration while investigating the problem.
Hi, our developers have just let me know that this problem will be fixed in the next release of the Types plugin. I will update this ticket when the new version is available for download and automatic update.
Hi, please find Types 3.0.7 now available for download or automatic update. Please install the latest version of Types and let me know if the issue is not fully resolved.
