Meteotemplate Forum

I ended up just doing a fresh install as I have not messed with the template since I first set things up. and I didn't need to do a database import as it appears what Weathercat worked all last night while I was asleep and uploaded all the missing data which I did not know it would do. Thus far ever...

Has anyone has luck with this? It should be as easy as exporting and then re-importing the database and then installing a fresh copy correct? DidI miss anything?

Ok I was able to locate it eventually. For my setup you see the following listed in /etc/nginx-rc/conf.d/WX.d/headers.conf the file contains the following if nosniff is enabled within Runcloud. # Do not edit this file # Editing this file manually might break RunCloud System # If you think there is a...

Correct, Runcloud errs on the side of caution and is probably more paranoid than it needs to be.

andyk1 wrote: ↑Mon Jan 14, 2019 11:18 pm I looked at it quickly but can't find where the “nosniff” is inserted? In the index.html? or htaccess or is at your hosts control panel settings?

I will look a little further when I get home to see where it is behind the scenes.

My host is Digitalocean: https://www.digitalocean.com/. I have multiple VMs running their but for my web server I am using their slightly above rock bottom Droplet plan: 1 vCPUs 2GB / 25GB Disk Ubuntu 18.04 LTS If you want to see all their pricing it is listed here: https://www.digitalocean.com/pric...

I mis-typed, it isn't a PHP setting but rather its part of cross site/cross script vulnerabilities in Apache/Nginx. It is a pretty deep rabbit hole but I use a control panel called Runcloud that manages my web server, etc hosted on a VM with Digitalocean. and it has several security settings enabled...

No I'm pretty sure it was the Mime Sniffing Protection setting in PHP, if I toggle that back on it breaks. I did also disable the solar sensor as my station does not currently support that sensor type just in case.

I think I figured it out, I disabled Mime Sniffing Protection in PHP on the subdomain. Does that look right now?

Tht file does have values in it , I am sending from my station to the template via the api.php. {"U":1547505626,"B":323,"W":4,"G":4,"H":91,"T":0.1,"HIN":61,"TIN":15.1,"RR":0,"R":0,"P":1027.2...

I just checked the scripts myself and yeah nothing looks like a hard coded path. I stepped PHP down to 7.1 to test.

andyk1 wrote: ↑Mon Jan 14, 2019 10:08 pm The only thing I can think of at this point is delete and reinstall the ssGauges Block and steelSeries plugin and start over

I removed both, re-downloaded the plugin and block and re-installed them, still looks to be the same.

Good point, I removed the non SS block but I do not see a change.

Yes I had changed a few of the settings so I just went back and changed a lot more of them but I am not seeing any changes yet.

I double checked the plugin and the clock and both show that the initial settings have been created.

I just enabled the SS gauges on the main page, i have been running without the SS gauges until now.
The normal gauges are first and the SS gauges are second for comparison.

SO the gauges are loading for you? I still do not see the gauges loading even when I explicitly go to the non ssl version of plugin page.

I have re-installed the plugin and removed the cert from the sub domain with no change. Any other ideas?

I have the settings created and the SSL cert is issued every 90 days automatically and has not had any issues thus far on anything else on my web server. I use the cert because it is free from Comodo via Let's Encrypt.

I am having a similar issue with mine, they do not seem to load at all for some reason.

https://wx.gatewayy.net/plugins/steelSeries/