Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Ingognito does not show the problem so I must have something as an add-in that is causing the problem (It could be Avast or something like that messing with the Security). I got this listed in the console on this page:
The fonts appear to be Google Fonts, not sure if you load them or not directly. Could be through Google Ads or something. This is where the fonts.gstatic.com is coming from. Likely my anti-virus software watching the web traffic blocking the non-https load. You can find this reference here: https://developers.google.com/fonts/faq
Search the page for gstatic it is about 1/2 down the page. Really not sure there is an action for you to take here, but more of an FYI. I tried disabling Anti-virus, but I might not be flushing the cashe as it still shows. My guess is the fonts are embedded into a script by Double Click or Google Ads..
No worries, it isn't impacting my browser any longer and can edit and respond to messages.
Well, the thing is that most severs in the last few years should automatically be configured to upgrade insecure requests to prevent the mixed content block message. It's a server setting. Ours is already enabled.
So that means a third party is injecting code into our site, and is doing it in a bad way that could at the very least use the URI of // instead of protocol://, so that http stays http:// and https:// stays https://.
In this case, the problem is something on your side and not FIO.
Minor change, my other site https://www.bmcharts.com/ which I use only for myself, will now have its images directly embedded under the primary nexusfi.com domain.
For example:
This URL:
Is originally coming from bmcharts, but being internally redirected to nexusfi.com. This is just to save DNS queries and boost performance, and possibly a boost for SEO since bmcharts is closed/private anyway.
I am only sharing this because if you see any problems with broken images, please report it. Over the years, I've integrated bmcharts more and more into the site out of convenience so just need to ensure I didn't break anything.
Yes, the plugin code wasn't decoding Unicode correctly, I imagine this was the same with the old server? Simple fix to switch to Unicode function in code.
Rrrracer
Looking good on this end... I must have given you an easy one
Corrected edge case scenario where an automatic bounce (non-deliverable) email wasn't being unsubscribed from the email list in all cases (in the case where they used a forwarding service and the forwarding service bounced, not matching our original recorded email).
Unsubscribes are important, and we do our best to make them effortless and prominent on emails. So please report any problems with unsubscribes.