Link to home
Start Free TrialLog in
Avatar of Julian Hansen
Julian HansenFlag for South Africa

asked on

Migrating Wordpress to HTTPS does not update path for enqueued resources

We have moved a WordPress site over to HTTPS, however some of the scripts / css files are still being referenced on http - resulting in a broken site as these requests are blocked due to mixed active content violation.

Summary
* This is a WP site that runs off a menu option of the main site - which is not WP. In other words you have www.domain.com - normal site and from there a link to www.domain.com/blog - this is a WP site specifically to run the blog.
* The site is hosted on one domain but dashboard (wp-admin) is hosted on a different domain
* The requests to the blocked content files are on the admin domain (resource domain which I think is an Amazon S3 bucket - but I don't have confirmation on this - my access is limited)
* Requests to the domain a redirected to https://
* The site url's (admin and site) in the settings were changed to https
* The links in question are not in the database but are generated with the WP enqueue_scripts and enqueue_styles - we have done the URL search and replace on the database but that had no effect on the scripts and JS files
* The Wordpress HTTPS plugin is installed (https://wordpress.org/plugins/wordpress-https) and the SSL Host is configured to be the Admin domain.

I am under pressure to get this working but have N other things to do so don't have to fiddle about with WP.

Hoping someone out there has seen this before and knows what has been missed.


I suspect that as part of the enqueue scripts call because the resources are not the same as the site domain
Avatar of Crazy Horse
Crazy Horse
Flag of South Africa image

Hi Julian, this is a bit advanced for me so what I am about to post probably won't help but I just thought I would put it out there. I used this https/ssl plugin on a wordpress site and it was like magic how it just made https work.

https://wordpress.org/plugins/really-simple-ssl/

Apologies if I completely missed the point here.

It has automatic mixed content fix which is why I thought it might help.
Avatar of David Favor
https://wordpress.org/plugins/really-simple-ssl/ conflicts with many Apache SSL configs, so can cause impossible to debug problems.

Several actions to try, to resolve SSL related problems.

Best resolution is to find + fix all http protocol references in your database.

I can't really follow your notes above clearly, so I'll just use a generic example for a foo.com named site.

# Appending --dry-run shows table change counts to be made, without making them.
# Remove --dry-run to actually rewrite your database.

# Correct all site links
wp search-replace --report-changed-only "http://foo.com" "https://foo.com" --precise --recurse-objects --all-tables --dry-run
wp search-replace --report-changed-only "http://www.foo.com" "https://foo.com" --precise --recurse-objects --all-tables --dry-run

# Correct all 3rd party links
# Be sure you have a backup before you do this.
wp search-replace --report-changed-only "http://" "https://" --precise --recurse-objects --all-tables --dry-run

Open in new window


Next you can use Chrome -> right mouse click -> inspect -> console -> reload to show all http://... assets to fix + hand fix them through your site.

Some problems are near impossible to fix. For example, the Optimize Press plugin breaks SSL in many subtle ways.

To fix subtle breaks you can't seem to fix no matter what you do...

https://wordpress.org/plugins/ssl-insecure-content-fixer/ attempts fixing SSL problems with varying degrees of speed.

Lowest setting is fastest. Highest setting will fix any problem. Medium settings to fix things like Optimize Press nonsense.

Just keep increasing the level of fix, till all problems disappear.

BTW, lowest resource usage fix will be rewriting the database with wp (wp-cli.phar) mentioned above.
Avatar of Julian Hansen

ASKER

Best resolution is to find + fix all http protocol references in your database.
Already done - these are not database references they are created with wp_enqueue_script and wp_enqueue_stylesheet i.e. generated by code.

Using WP CLI is something that is part of my standard process and was my immediate goto when the client asked for assistance for getting their blog up and running after they tried to move it over to HTTPS. My thinking was this was a quick fix - dumped the db - restored it and ran the  CLI search and replace it fixed around 700 URL's but not the ones causing the actual problems with the site - which was caused by the stylesheets and scripts that were being blocked due to a mixed content violation.

If you view source on the site all the <link ...> <script ...> references to the resource site (the domain the admin is on) are http. All of these are created with enqueue functions.

So, the problem (in my mind) is something inside WP has not been set correctly and WP is generating the wrong URL's for its script and link references. (this is where my earlier question comes in - those links are generated using the WP_PLUGIN_URL constant and that is changing its value).
Likely good to just post the URL of your site, so people can look at exact problem.

And the plugin I listed above is how I fix many site, so badly broken, hours will be required to fix them correctly.
Thanks Dave,

I just tried that plugin, tried all the options up to capture all. I believe the problem has to do with something in WP that is not translating enqueued scripts / stylesheet paths to https correctly and I suspect it has something to do with the fact that the Wordpress Address and Site address point to different domains. All the problem URL's are those that point to the Wordpress Address URL.

I have zero experience with WP sites setup in this way so I am lacking in knowledge about any WP specific setup that one needs to take into account when doing this.

I have had clearance from the client to post the link to the domain.

http://www.trudiamonds.co.uk/blog
Another plugin worth checking out perhaps,

https://wordpress.org/plugins/ssl-insecure-content-fixer/

Selecting the simple option to run will:

This is the fastest and recommended method for all beginner users. It automatically fixes the mixed content error in WordPress for scripts, stylesheets, and WordPress media library images.

It seems like it might fix the wp_enqueue_style issue for you.

Here is the article with instructions on how to use:

https://www.wpbeginner.com/plugins/how-to-fix-the-mixed-content-error-in-wordpress-step-by-step/

And, here is some info on moving wordpress files outside of the root. Not sure if this is applicable. (Method II (With URL change))

https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory

And lastly:

https://deliciousbrains.com/move-wordpress-root-subdirectory/

Are you not able to manually change wp_enqueue_style in functions.php to https?
@Black Sulphur,

Thanks for the post.

The site was setup by another developer - I am a gate crasher at this party.

The plugin you suggest above Dave has already suggested - does not fix the problem.

The url's are not in the code base - first thing I did was search the DB and code base for all instances of http - did not turn up anything - so this is not a case of the site having bad urls configured. WP is generating those URL's on the fly as part of the enqueuing process and changing the https to http.

I have another question open where I explain that somehow a PHP constant (WP_PLUGIN_URL) is changing its value mid execution which is not supposed to be possible - I have narrowed down the problem to this area of the code - despite being defined as an HTTPS URL at the start of execution - when it comes to dumping the link and script references in the <head> the value of the "constant" changes to http:

More detail in this question https://www.experts-exchange.com/questions/29113709/WP-CONTENT-URL-Constant-changes-its-value-mid-execution.html
Apologies, didn't check the link properly and didn't realise that the same plugin was posted by David. Sorry, David!

Regarding WP_PLUGIN_URL, not sure if this is what you are referring to:

https://wordpress.org/support/topic/wp_plugin_url-doesnt-take-ssl-into-account/

https://wordpress.org/ideas/topic/wp_plugin_url-doesnt-take-ssl-into-account

https://teamtreehouse.com/community/wppluginurl-is-used-but-this-should-not-be-used-according-to-wp-codex

This is old but may be relevant

https://snippets.webaware.com.au/snippets/cleaning-up-wordpress-plugin-script-and-stylesheet-loads-over-ssl/

If I understand some of these correctly, it might be that a plugin should use  plugins_url() but is using WP_PLUGIN_URL instead which causes the issue. That is what I understand of the first link I sent you.
The reason WP_PLUGIN_URL is in the mix is because I traced this to the WP function plugins_url() - the debug dumps I am doing are in that function where it uses WP_PLUGIN_URL.

So the calls are being made to plugins_url()

Keep suggesting though.
Why does the path looks so weird?

http://trudiamondsblog.exact3ex.co.uk/wp-content/plugins/....

instead of:

https://www.trudiamonds.co.uk/wp-content/plugins/....


if you go here you can actually see the blog laid out properly.

http://trudiamondsblog.exact3ex.co.uk/

Maybe the above url also needs to be forced to https because it works both on http and https:

https://trudiamondsblog.exact3ex.co.uk/
Because the way they have set it up is so that the backend (engine) runs off a different domain.

This is fairly standard in WP installations - if you go to settings General - you will see there are two options for a url
Wordpress Address (URL)
Site Address (URL)

This is so you can have your blog as part of your main site (which may not be WP) and not have all the WP files cluttering your root.

I suspect that there might be something in that part of the setup that is at play - but have not had a enough experience with that sort of setup to be able to narrow it down.
It wasn't with a Wordpress site so probably won't apply, but recently I had a site up with SSL and if you went to the url https://mydomain.com it worked 100% but if you went to even https://www.mydomain.com I received a bunch of those mixed content warnings even though in my header and footer I had https links to css and js files. It was still showing as http in the browser

So, I just changed my .htaccess to force it to go to https://mydomain.com and that solved my issue.

I am clutching at straws due to inexperience but maybe just as a test, you could set your htaccess to force the https on that blog because should it be working like it is now on both http and https? It runs perfectly on SSL and non-ssl which is a bit confusing. Well, to me anyway.

http://trudiamondsblog.exact3ex.co.uk/

https://trudiamondsblog.exact3ex.co.uk/

I just did this but it might need some modification.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,NE,R=301]

Open in new window

Jus too add, the reason I suggest the forcing of .htaccess is because the main domain and blog domain are different in terms of http and www.

The main domain is http://www and the blog is just http:// and if you try add www to the blog url you get a nasty error.

So, if you go to https://trudiamonds.co.uk/ then the site doesn't work at all and if you go to https://www.trudiamondsblog.exact3ex.co.uk/ then the blog doesn't work at all
It is a good suggestion except that .htaccess is a server side solution and the problem is in the browser.

Let's go back to how a page loads.
1. You request a page from the server - in this case on an HTTPS url
2. The server generates a page and sends it back to the browser which starts parsing it.
3. All good. Now the browser starts rendering the page - when it comes across a <link> <script> or <img> reference it pulls the URL from that resource and makes a separate request back to the server for that resource.
Here is where we hit the problem. Because the original request is on HTTPS when the browser sees an HTTP reference to a resource it blocks it with a Mixed Content warning. So the request to the server is never made and .htaccess never enters into the equation.

This is in the generation process of the page that is sent to the browser. It is being sent with HTTP references to resources instead of HTTPS - so we need to find out why WP is generating HTTP references instead of HTTPS.

But keep the ideas coming.
ASKER CERTIFIED SOLUTION
Avatar of Julian Hansen
Julian Hansen
Flag of South Africa image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Glad you got it sorted!