New PHP Upload Process

[griffo42]

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

I'm sure I need something else other than what you suggest for the path. Perhaps this below will help you advise me what I need to do with the extra files set up.

My directory setup is:

All files for my Saratoga site are contained in the public_html folder on the server.
All files for my Cumulus site are contained in a folder named cumx in the public_html folder.
Similarly, all files for my Cumulus MX UI site are contained in a folder named mxtestv2 in the public_html folder.
Similarly, all files for my Cumulus HWS site are contained in a folder named pwsWD in the public_html folder.

Cumulus site works perfectly: the other 3 do not.

[HansR]

My directory setup is:

All files for my Saratoga site are contained in the public_html folder on the server.
All files for my Cumulus site are contained in a folder named cumx in the public_html folder.
Similarly, all files for my Cumulus MX UI site are contained in a folder named mxtestv2 in the public_html folder.
Similarly, all files for my Cumulus HWS site are contained in a folder named pwsWD in the public_html folder.

Cumulus site works perfectly: the other 3 do not.

The question is: where is your upload.php located?

[griffo42]

Here are 2 screenshots of part of my cumulus.ini file which may be pertinent to the above:

Screenshot 2023-11-13 170447.png

Screenshot 2023-11-13 170354.png

[griffo42]

My directory setup is:

All files for my Saratoga site are contained in the public_html folder on the server.
All files for my Cumulus site are contained in a folder named cumx in the public_html folder.
Similarly, all files for my Cumulus MX UI site are contained in a folder named mxtestv2 in the public_html folder.
Similarly, all files for my Cumulus HWS site are contained in a folder named pwsWD in the public_html folder.

Cumulus site works perfectly: the other 3 do not.

The question is: where is your upload.php located?

My upload.php is located in the cumx folder cited above.

[HansR]

My directory setup is:

All files for my Saratoga site are contained in the public_html folder on the server.
All files for my Cumulus site are contained in a folder named cumx in the public_html folder.
Similarly, all files for my Cumulus MX UI site are contained in a folder named mxtestv2 in the public_html folder.
Similarly, all files for my Cumulus HWS site are contained in a folder named pwsWD in the public_html folder.

Cumulus site works perfectly: the other 3 do not.

The question is: where is your upload.php located?

My upload.php is located in the cumx folder cited above.

OK, that's the issue.

From there you define all your uploads relative to that directory. So if you want to upload a file to the webroot (public_html) you tell CMX to upload it to ../ so your CUtags-new.php upload destination becomes

Code: Select all

../CUtags-new.php

Etc... for all uploads.

The above assumes you defined your PHP-URL correctly but since your cumx site seems correct I take it that is OK.

[HansR]

NOTE if the PHP upload procedure complains you step out of the permitted directory structure I would advise to put upload.php in the public_html and upload everything from there. Since all directories are under public_html you stay withing the permitted tree. In that case your upload for CUtags would become:

Code: Select all

cumx/CUtags-new.php

[EDIT} Maybe public_html is the best location after all for the upload.php.

[griffo42]

@HansR
After, what I thought was following your advice very carefully, i have been unable to get the PHP uploads working, I have now reverted to FTP uploads.

Thanks for your help.

[HansR]

Strange situation, you are the first I hear from who can't upload over https
Anyway, maybe you get a brain wave sometime and try again.

[Mapantz]

upload.php has stopped working for me, since last night.

Code: Select all

2023-12-09 01:51:47.087 PHP[83]: Sending via GET
2023-12-09 01:51:47.097 PHP[83]: Uploading to realtimegauges.txt
2023-12-09 01:51:47.097 PHP[83]: Sending via GET
2023-12-09 01:51:47.097 PHP[83]: Uploading to realtime.xml
2023-12-09 01:51:47.097 PHP[83]: Sending via POST
2023-12-09 01:51:47.097 PHP[83]: Upload to realtime.txt: Response code = 422: 422
2023-12-09 01:51:47.097 PHP[83]: Upload to realtime.txt: Response text follows:
Error: TimeStamp is out of date
Data TS   = 1702086707
Server TS = 1702083845
2023-12-09 01:51:47.108 PHP[83]: Upload to realtimegauges.txt: Response code = 422: 422
2023-12-09 01:51:47.108 PHP[83]: Upload to realtimegauges.txt: Response text follows:
Error: TimeStamp is out of date
Data TS   = 1702086707
Server TS = 1702083845

2023-12-09 01:51:47.162 PHP[83]: Upload to realtime.xml: Response code = 422: 422
2023-12-09 01:51:47.162 PHP[83]: Upload to realtime.xml: Response text follows:
Error: TimeStamp is out of date
Data TS   = 1702086707
Server TS = 1702083845

[water01]

Stop using the GET for small files by disabling it in the Advanced settings, worked for me on my site. Makes no difference that I can see to the upload, but the occasional Get failures disappeared.

[Mapantz]

Stop using the GET for small files by disabling it in the Advanced settings, worked for me on my site.

Tried that, didn't work.

[mcrossley]

Your server time is 138 seconds ahead of your MX time. One of them is not synchronising it's clock.

[Mapantz]

Your server time is 138 seconds ahead of your MX time. One of them is not synchronising it's clock.

I contacted my host and told them it stopped working at 01:25. I got this back..

I have switched the PHP version to 7.4 and also disabled the following code in the php.ini file which did the trick.
zlib.output_compression = On
zlib.output_handler = ob_gzhandler

It was already on PHP 7.4 and I hadn't changed any settings

[mcrossley]

Your server time is 138 seconds ahead of your MX time. One of them is not synchronising it's clock.

I contacted my host and told them it stopped working at 01:25. I got this back..

I have switched the PHP version to 7.4 and also disabled the following code in the php.ini file which did the trick.
zlib.output_compression = On
zlib.output_handler = ob_gzhandler

It was already on PHP 7.4 and I hadn't changed any settings

Totally irrelevant afaics, the error messages are clear, the script had compared the time stamp from MX and the server time and found them adrift - nothing to do with compression.

[water01]

That is a question I have been meaning to ask, what version of PHP do you advise running Mark.

I am trying to get all my PHP up to 8.0 but if you have not tested against it, it may be a problem.