Title: Problem when switching to https
Last modified: June 7, 2020

---

# Problem when switching to https

 *  Resolved [gaverpro](https://wordpress.org/support/users/gaverpro/)
 * (@gaverpro)
 * [6 years ago](https://wordpress.org/support/topic/problem-when-switching-to-https/)
 * Hello,
    Why didn’t anything change in the plugin’s cache folder / wp-content /
   uploads and all the links remained with Http (687 hits in 41 files) after the
   site switched to https? Clearing the cache gave nothing. The cache has been cleared
   through this button [https://prnt.sc/svdm3j](https://prnt.sc/svdm3j) At first,
   I thought that the point is what you write here [https://prnt.sc/svdmas](https://prnt.sc/svdmas)
   Those, just the plugin saves the old cache for 3 months. But after that, I checked
   and did not find any links with https in the cache folder. It seems that the 
   site is working correctly only thanks to this included option [https://prnt.sc/svdlss](https://prnt.sc/svdlss)
   Well, the strangest thing is, when I got used to the plugin a bit and found out
   that I can also clear the cache in the settings, I went into the settings and
   saw this picture [https://prnt.sc/svdf21](https://prnt.sc/svdf21) Although before
   that, after clearing the cache, I did a lot of navigation on the pages of the
   site. Other caching plugins are not yet used on the site. I can not understand
   anything.
    -  This topic was modified 6 years ago by [gaverpro](https://wordpress.org/support/users/gaverpro/).
    -  This topic was modified 6 years ago by [gaverpro](https://wordpress.org/support/users/gaverpro/).

Viewing 3 replies - 1 through 3 (of 3 total)

 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [6 years ago](https://wordpress.org/support/topic/problem-when-switching-to-https/#post-12956442)
 * Hi,
 * If you are purging the cache via FVM, old files will remain on the directory 
   for some time (you can delete them manually actually).
 * This system exists because there are some hosting providers that use very aggressive
   page cache and refuse to purge it on demand, which would result in 404 cache 
   files if we were to delete it right away (because the html cache would still 
   be pointing to them).
 * That being said, when you purge the cache the file names are incremented, so 
   the old ones are there, but no longer in use (unless you or your server uses 
   page caching like the one I described earlier).
 * The key there, is to look at the file name.
    If the file names for the css and
   js files are changing after purging and visiting the site in anonymous mode, 
   then you are doing things correctly. If they are not changing (the first part
   of the file name is a timestamp) then you have page caching going on that is 
   not being cleared after you purge FVM.
 * Assuming the files are changing names, they will be fresh and get all settings
   from the database. References inside of css files will either be relative or 
   absolute paths depending on the plugin being merged. By default, it’s relative
   so it works both via http and https without further changes.
 * Now, specifically in regard of migrating from http to https, and assuming there
   is no cache going on, this is the typical case where the migration is incomplete.
 * I advise you to follow the correct steps to ensure the http to https migration
   is done properly, else FVM may still be reading that your site is configured 
   as http from the database, even if you changed it somewhere else.
 * The correct steps are:
 * **(backup everything)**
 * **For the database:**
 * a) Install a plugin like better search and replace
    b) Use it to replace all `
   http:` with `https:` occurrences on the database (use a plugin, do not try to
   do that directly on the database administration tool)
 * **If you prefer wp-cli, I suggest:**
 *     ```
       wp search-replace 'http:' 'https:' --precise 
       wp transient delete --all --allow-root
       wp cache flush --allow-root
       ```
   
 * **For the files:**
 * 1) Check your `wp-config.php` and delete (or adjust to https) any `WP_HOME` or`
   WP_SITEURL` references.
 * 2) If you have edited your theme files (or hired someone in the past), it’s also
   possible that they hardcoded the http url on the theme or some plugin. I would
   suggest inspecting the files one by one and check for it, especially your theme.
 * If you are on Linux and use the command line, you can find references to your
   domain in the files (there should be zero usually, if you follow the code standards).
   I use something along these lines to find references.
 * `grep -rl --include="*.php" --include="*.js" --include="*.css" "http://yourdomain.
   com" ./`
 * Be sure to try `www` as well as escaped entries, such as `http:\/\/yourdomain.
   com`
 * Once you are certain that there are no `http://yourdomain.com` references on 
   both the database and your files, you can then purge FVM cache and any other 
   page cache (and OP Cache) on the server and the migration would have been completed
   correctly.
 * If you skip these steps, something is bound to break.
    I include the option to
   force https, but that is only for the plugin to use https whenever it needs to
   check the protocol in use, instead of getting it from the database.
    -  This reply was modified 6 years ago by [Raul P.](https://wordpress.org/support/users/alignak/).
    -  This reply was modified 6 years ago by [Raul P.](https://wordpress.org/support/users/alignak/).
 *  Thread Starter [gaverpro](https://wordpress.org/support/users/gaverpro/)
 * (@gaverpro)
 * [6 years ago](https://wordpress.org/support/topic/problem-when-switching-to-https/#post-12973662)
 * Hi Raul,
 * Thank you for such a comprehensive answer.
 * As for the transition to https, everything was done at a high professional level
   and there were no problems with that. The specialist knows his job.
 * It was not surprising that in old files that are not specifically deleted there
   are links from [http://](https://wordpress.org/support/topic/problem-when-switching-to-https/?output_format=md),
   the question was why there are no new files in which links with https should 
   have been.
 * But I checked it now, 3 days later, and now they appeared.
    The picture is now
   like this: as for links with http:// – 680 hits in 40 files as for links with
   https:// – 928 hits in 146 files
 * I do not understand what you are writing about relative links.
    All links in 
   the cache files are absolute.
 * But it’s not clear how the cache works for you at all.
    There are a lot of cache
   files in the folder, as I wrote above, but in this section, there is such a picture
   [https://prnt.sc/svdf21](https://prnt.sc/svdf21) The cache is zero.
 * I noticed that this happens when this setup is done here [https://prnt.sc/sy41b7](https://prnt.sc/sy41b7)
   
   But, as for the CSS files, here is the following setting for them: [https://prnt.sc/sy431b](https://prnt.sc/sy431b)
   In such cases, usually, the cache grows even faster, and your plugin shows 0.
   In addition, I see this message: “There are no merged CSS files listed here because
   you are inlining all CSS directly.” [https://prnt.sc/sy450o](https://prnt.sc/sy450o)
   Which makes me even more confused. What does this entry mean? This is not your
   plugin made embedding CSS inline, but someone else?
 * Another question regarding a different setting. This one is [https://prnt.sc/sy476o](https://prnt.sc/sy476o)
   
   Do I understand correctly that this setting only works for Google Lighthouse?
   But why, then, with this setup, when measuring in GTmetrix, the following happens?
 * When this setting is there, then I see this picture here [https://prnt.sc/sy4cum](https://prnt.sc/sy4cum),
   i.e. defer works for js files.
    If the option is disabled, then in GTmetrix there
   is no longer deferred, but async [https://prnt.sc/sy4erq](https://prnt.sc/sy4erq)
   It’s not clear why GTmetrix reacts to this setting?
 * On GTmetrix, in principle, async should always be loaded, in accordance with 
   the settings of another plugin (while js is practically disabled on your plugin)
   and when async, then naturally the speed on GTmetrix is ​​immediately higher.
 * When I turn on this setting [https://prnt.sc/sy476o](https://prnt.sc/sy476o),
   then it should improve the performance on the PSI, but should something change
   for GTmetrix? Now on PSI, the indicator is improving, while on GTmetrix it is
   falling.
 *  Plugin Author [Raul P.](https://wordpress.org/support/users/alignak/)
 * (@alignak)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/problem-when-switching-to-https/#post-13263440)
 * > As for the transition to https, everything was done at a high professional 
   > level and there were no problems with that. The specialist knows his job.
 * I believe you, however people forget stuff and this is a very common situation.
   The database should still be updated from http to https, even if it was done 
   before.
 * In addition, any files that have hardcoded http versions, also have to be updated
   to https.
 * FVM will merge what is there and will only try to enforce https when possible.
 * Furthermore, if you don’t have a 301 redirect from http to https, pages can get
   cached when someone access the http version and being used for the https version.
 * Either way, regardless of who did the http to https migration, it looks incomplete.
   
   I’ve done http to https migrations thousands of times, and I often see experienced
   engineers miss some of these steps… so repeating the database and file http to
   https will either fix what is left (fixing it), or not find anything (best case
   scenario).
 * —
 * > I do not understand what you are writing about relative links.
   >  All links in
   > the cache files are absolute.
 * Background images, fonts and other static assets inside fvm cache files are meant
   to be relative to it’s cache directory. If you use absolute paths inside css 
   files (which should not be the normal case unless you are using a cdn for that)
   then they can be absolute.
 * —
 * > But it’s not clear how the cache works for you at all.
   >  There are a lot of 
   > cache files in the folder, as I wrote above, but in this section, there is 
   > such a picture [https://prnt.sc/svdf21](https://prnt.sc/svdf21) The cache is
   > zero.
   > I noticed that this happens when this setup is done here [https://prnt.sc/sy41b7](https://prnt.sc/sy41b7)
   > 
   > But, as for the CSS files, here is the following setting for them: [https://prnt.sc/sy431b](https://prnt.sc/sy431b)
   > In such cases, usually, the cache grows even faster, and your plugin shows 
   > 0. In addition, I see this message: “There are no merged CSS files listed here
   > because you are inlining all CSS directly.” [https://prnt.sc/sy450o](https://prnt.sc/sy450o)
   > Which makes me even more confused. What does this entry mean? This is not your
   > plugin made embedding CSS inline, but someone else?
 * If you are inlining css, there are no public cache files because nothing is merged.
   
   Inlining each css file like you did, will read the css files into a temporary
   cache file and inline it, however since those files are not public, they don’t
   count towards the public cache size. In addition, you disabled js optimization,
   so the plugin completely ignores javascript.
 * I agree that the cache should consider the intermediate cache size, but it was
   made to count only the public css files, and not when you are inlining it. Btw,
   you should only inline css if it’s small… else, performance is going to be bad.
 * Hire a developer to help you with that if you are not sure which method to choose.
   This plugin is for advanced users and developers.
 * —-
 * > Another question regarding a different setting. This one is [https://prnt.sc/sy476o](https://prnt.sc/sy476o)
   > 
   > Do I understand correctly that this setting only works for Google Lighthouse?
   > But why, then, with this setup, when measuring in GTmetrix, the following happens?
 * That feature is useful for developers to test the impact of certain scripts or
   actions on the scores, and then decide if that’s something they should work on
   or not.
 * —
 * > When this setting is there, then I see this picture here [https://prnt.sc/sy4cum](https://prnt.sc/sy4cum),
   > i.e. defer works for js files.
   >  If the option is disabled, then in GTmetrix
   > there is no longer deferred, but async [https://prnt.sc/sy4erq](https://prnt.sc/sy4erq)
   > It’s not clear why GTmetrix reacts to this setting?
 * That simply means, your scripts were already async.
    Enabling the option, will
   force defer. Disabling it, will go back to whatever it was.
 * Don’t use multiple plugins to force async scripts without knowing for sure, that
   they can be async. If they are already async, there is no need to use this option
   on FVM as you are just doing the same.
 * FVM should be used alone, without any other plugins merging or processing scripts/
   css.
 * Either way, the main topic of this post was about https, so the other features
   are just a matter of testing what works for your site.
    -  This reply was modified 5 years, 10 months ago by [Raul P.](https://wordpress.org/support/users/alignak/).

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Problem when switching to https’ is closed to new replies.

 * ![](https://ps.w.org/fast-velocity-minify/assets/icon-128x128.jpg?rev=1440946)
 * [Fast Velocity Minify](https://wordpress.org/plugins/fast-velocity-minify/)
 * [Support Threads](https://wordpress.org/support/plugin/fast-velocity-minify/)
 * [Active Topics](https://wordpress.org/support/plugin/fast-velocity-minify/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/fast-velocity-minify/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/fast-velocity-minify/reviews/)

 * 3 replies
 * 2 participants
 * Last reply from: [Raul P.](https://wordpress.org/support/users/alignak/)
 * Last activity: [5 years, 10 months ago](https://wordpress.org/support/topic/problem-when-switching-to-https/#post-13263440)
 * Status: resolved