Problem when switching to https

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" "https://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 https://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 4 years, 5 months ago by Raul P..
• This reply was modified 4 years, 5 months ago by Raul P..

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 https://, 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 https:// – 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 The cache is zero.

I noticed that this happens when this setup is done here https://prnt.sc/sy41b7
But, as for the CSS files, here is the following setting for them: 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
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
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, 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
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, 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.

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 The cache is zero.

I noticed that this happens when this setup is done here https://prnt.sc/sy41b7
But, as for the CSS files, here is the following setting for them: 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
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
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, 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
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 4 years, 3 months ago by Raul P..