Can you please respond to this thread and let us know where the spiner URLs are stored in the database so we can ensure they get updated when moving a site over?
https://toolset.com/forums/topic/moved-to-https-but-ajax-loader-gif-still-being-loaded-over-http/#post-1581135
The images themselves are in the plugins wp-content/plugins/wp-views/embedded/res/img/ folder.
Each View is stored like a "native" WordPress post (the entire View) in the database posts table.
The chosen Spinner for each View is saved in a Post Meta (_wpv_settings), which holds the URL to the file as value, amongst many other things (it's a serialized array)
Does this help?
Ok, so if it is serialized then how do we ensure the URL gets updated when transferring a site from one URL to another?
We have had reports of this in past.
It was not possible to provide a full solution to the problem and was released with Views 2.7.5
This is how it works:
1. Create a site in non-SSL.
2. Add a View and set it to paginate with AJAX using one of the builtin Views spinners.
3. Add another form and set it to paginate using a custom spinner that you need to upload.
4. Add another View and add some frontend search filter, set it to update results with AJAX, and add a wpv-filter-spinner shortcode to the search form editor, selecting one of the offered spinners.
5. Move the site to SSL.
6. Now, issues will happen (or not) as follows:
- the builtin spinner still works on the first View, because its URL was converted on-the-fly to SSL.
- when editing the first View, the right builtin spinner is selected in the pagination options.
- the custom spinner still works on the second View, because its URL was converted on-the-fly to SSL.
- when editing the second View, the custom spinner URL in the setting input text field has a proper https:// schema.
- the builtin spinner still works on the third View, because its URL was converted on-the-fly to SSL.
So, all saved and built-in spinners do not need to edit.
Note, the actual URLs in the backend will NOT be updated (for example in shortcode attributes)
But the front end will work
I tested and confirmed this works, hence any issue related to this behaving differently is either another issue or maybe due to compatibility or else
Can you please elaborate where and how precisely this issue still happens for you?
It seems you should not see any issue at all, after migrating properly to HTTPS.
I found this on an older site that I migrated over 1.5years ago so it may not be an issue when migrating new sites. I'll be sure to double-check this next time I move a site.
