New PHP Upload Process

[water01]

Ctrl+F5 to refresh the cache?

[Vegit8]

Ctrl+F5 to refresh the cache?

Nope - that makes no difference.
As far as I was aware the page is reading data from the remote end, there is no caching locally.

If you hover over the LED the tooltip says "weather station is offline", which it clearly is not, as the page recovers after a couple of cycles...

[HansR]

I looked with the debugger and found that initially it finds realtimegauges.txt with the correct timestamp. The second and subsequent reads find a realtimegauges.txt with timestamp of 13:21 (always the same) which definitely sets the LED to RED.
The URL is in both cases the same and points to http://geoffwebber.co.uk/weather/realtimegauges.txt.

So the question is: where and how does it load a realtimegauges.txt with a time of 13:21.
It seems to be somewhere on your server and is not overwritten. Is there a version with no delete rights?

Can you locate that file and see what its rights are? It may shed some light on this.

[EDIT:} and the upload of realtimegauges.txt goes without fault, you can find the new versions always on the URL http://geoffwebber.co.uk/weather/realtimegauges.txt. Look at the timestamp to check. So it loads another file!

[freddie]

There's some JavaScript that loads the latest realtimegauges.txt data. When it requests the data it appends the epoch number to the request - this is a cache-busting measure, and the epoch number should be set to the current time. So if you do requests using the same epoch number you end up with the previously requested data (from cache), as the number should change each time the data is requested. So you're not really requesting the data for a specific time, just the latest data.

I am at a loss to explain why you see this behaviour, unfortunately. It will be browser-specific, though, as JavaScript is executed in your browser, not on the server.

[broadstairs]

There's some JavaScript that loads the latest realtimegauges.txt data. When it requests the data it appends the epoch number to the request - this is a cache-busting measure, and the epoch number should be set to the current time. So if you do requests using the same epoch number you end up with the previously requested data (from cache), as the number should change each time the data is requested. So you're not really requesting the data for a specific time, just the latest data.

I am at a loss to explain why you see this behaviour, unfortunately. It will be browser-specific, though, as JavaScript is executed in your browser, not on the server.

Which means if you have JavaScript disabled this is likely to cause a problem!

Stuart

[freddie]

Which means if you have JavaScript disabled this is likely to cause a problem!

Stuart

The Cumulus default site uses JavaScript in many places. I can't see it functioning at all without JavaScript. But that's in line with all modern websites.

Hopefully users who disable JavaScript are very much in the minority these days.

[Vegit8]

I am at a loss to explain why you see this behaviour, unfortunately. It will be browser-specific, though, as JavaScript is executed in your browser, not on the server.

Following on from the browser comment, I swapped from Chrome (via Duck Duck GO add in) to Firefox.
I get the same result.

If I had Java script disabled (which I do not) then the gauges would never update (at least that is my understanding).

Now... I did not get this using my standard Chrome/Duck Duck GO set up before upgrading to the latest build of MX and changing to php uploads.
My previous build was 3154

I have not changed any of the web pages from one build to the other.

[mcrossley]

Just continually reading the realtimegauges.txt file I see the UTC time in it incrementing every few seconds, then it goes back to that old stale version for an update.

Do you have an old/second copy of Cumulus running in the background somewhere that is uploading the sale file?

[Vegit8]

Just continually reading the realtimegauges.txt file I see the UTC time in it incrementing every few seconds, then it goes back to that old stale version for an update.

Do you have an old/second copy of Cumulus running in the background somewhere that is uploading the sale file?

Second copy running = No - I have the potential for this disabled in any case via settings.

Now... And this may be due to my not fully understanding the differences between the FTP upload and the php processes.

In C:\CumulusMX\web I have an instance of realtimeguages.txt the date time of this file is 22/06 13:21 (this would be the time/date that is referred to in the status field when the LED is showing RED)
In C:\CumulusMX I have realtime.txt with the same date\time stamp

Settings in http://192.168.1.79:8998/extrawebfiles.html are like this...

extrawebfiles.png

Should I NOT be uploading the realtimeguages.txt file?
Why does the localised version of the 2 realtime .txt files not get updated to the current date / time?

Everything else in the php upload mechanism seems to work OK, I get the feeling that I have missed a step somewhere or have a misconfiguration.

Attached is my latest MXDiags

[HansR]

Just continually reading the realtimegauges.txt file I see the UTC time in it incrementing every few seconds, then it goes back to that old stale version for an update.

Do you have an old/second copy of Cumulus running in the background somewhere that is uploading the sale file?

Second copy running = No - I have the potential for this disabled in any case via settings.

Now... And this may be due to my not fully understanding the differences between the FTP upload and the php processes.

In C:\CumulusMX\web I have an instance of realtimeguages.txt the date time of this file is 22/06 13:21 (this would be the time/date that is referred to in the status field when the LED is showing RED)
In C:\CumulusMX I have realtime.txt with the same date\time stamp

Settings in http://192.168.1.79:8998/extrawebfiles.html are like this...

extrawebfiles.png
Should I NOT be uploading the realtimeguages.txt file?
Why does the localised version of the 2 realtime .txt files not get updated to the current date / time?

Everything else in the php upload mechanism seems to work OK, I get the feeling that I have missed a step somewhere or have a misconfiguration.

Attached is my latest MXDiags

I think you can remove the first two lines (realtimegauges and gauges-ss.htm) and the last line (the moon image) and configure those in the interface:

• Realtimegauges: Internet Settings=>Interval Configuration=>Real time Interval Settings
• gauges-ss you already skipped yourself so we don't bother
• moon image: Internet Settings=>Moon Image

Take care that the paths you define are relative to the location of upload.php so don't use a first slash.

I think that should be it.

[Vegit8]

I think that should be it.

Hans - Thank you
I have also deleted the errant realtime files - and all seems to be OK still.

I'll keep an eye on it!

Cheers

[griffo42]

I swapped over to PHP uploads yesterday, Sunday 12th November.

Since that time, extra webfiles uploads have not worked with my Saratoga based website.

Attached are 2 zip files from my MX Diags folder - one at the time of changeover and the other being the latest.

Can anyone please point me to the fix?

[griffo42]

Further to mine next above and to assist in problem solving, this is a screenshot of my Extra web files settings page.

Screenshot 2023-11-13 104911.png

[PaulMy]

Hi,

I swapped over to PHP uploads yesterday, Sunday 12th November.
Since that time, extra webfiles uploads have not worked with my Saratoga based website.

I can't follow all the errors and most seem to be extra web files related.

Code: Select all

2023-11-12 15:14:56.813 Realtime[80]: Uploading extra web file d:\CumulusMX\web\realtimegauges.txt to public_html/mxtestv2/realtimegauges.txt
2023-11-12 15:14:56.813 PHP[80]: Uploading to public_html/mxtestv2/realtimegauges.txt
2023-11-12 15:14:56.813 PHP[80]: Sending via GET
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/realtimetags.php: Response code = 500: InternalServerError
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/realtimetags.php: Response text follows:
Error: Cannot create the target file public_html/mxtestv2/realtimetags.php with this user kstwx197

2023-11-12 15:14:56.828 Realtime[80]: Uploading extra web file d:\CumulusMX\web\cldbaseCUtagsT.php to public_html/mxtestv2/CUtags.php
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/websitedata.json: Response code = 500: InternalServerError
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/websitedata.json: Response text follows:
Error: Cannot create the target file public_html/mxtestv2/websitedata.json with this user kstwx197

2023-11-12 15:14:56.828 Realtime[80]: Uploading extra web file d:\CumulusMX\web\cldbaseCUtagsT.php to public_html/mxtestv2/cldbaseCUtags.php
2023-11-12 15:14:56.828 PHP[80]: Uploading to public_html/mxtestv2/CUtags.php
2023-11-12 15:14:56.828 PHP[80]: Sending via GET
2023-11-12 15:14:56.828 PHP[80]: Uploading to public_html/mxtestv2/cldbaseCUtags.php
2023-11-12 15:14:56.844 PHP[80]: Sending via GET
2023-11-12 15:14:56.844 PHP[80]: Upload to public_html/mxtestv2/CUtags.php: Response code = 500: InternalServerError
2023-11-12 15:14:56.844 PHP[80]: Upload to public_html/mxtestv2/CUtags.php: Response text follows:
Error: Cannot create the target file public_html/mxtestv2/CUtags.php with this user kstwx197

Generally, unlike with FTP upload, with PHP upload you do not need the starting public_html in the remote path for extra files as the PHP upload is relative to where the upload.php script is located.

Enjoy,
Paul

[PaulMy]

Hi again,
Just saw your capture after I posted, and you should remove the public_html/ from your Destination filename. And the same in NOAA settings if you upload those.

Enjoy,
Paul