Ray, Thanks for your input.
Re testing - I had setup an XAMPP instal on a PC specially for the purpose of testing but then was diverted onto a LAMP install which I did not have configured correctly so the testbed was in limbo.
Have returned to XAMPP, completed the standard configuration and added folders and loaded the data. I found most of the issues you advised for which I thank you.
Have resolved them on the data summary page as well as a number of other minor issues on other pages.
It is evident that our hoster has the error level reporting turned well down as these errors are not reported by them and all the pages that had errors displayed as intended without indication of errors.
Also I find that in XAMPP these errors disappear and the page needs to be refreshed (sometimes more than once) to get them back. This makes it difficult to ensure that a change is in fact working as even when these errors are reported, in most instances, the intended result is displayed anyway. I would appreciate your recommendation regarding how to tweak the error level reporting in XAMPP - I am new to this so it takes some time to sort out this 'tuning'.
the metdate is code suggested by others to deal with non-midnight rollover times on new Years Day
"you have added the "$WX['$metdate']" variable to the code" ... "but did not test its proper operation!"
I do apreciate the metdate thing is problematic and that you do not see the need for it. The way it is coded in the sample pages posted in the earlier attachment is the only way the page displayed in the intended manner on our hosted site.
It is evident that I do not know the proper syntax to achieve the desired effect (of others) and that is why I specifically asked, when posting the attached files, that the code be checked by others which you have now kindly done. It was on our website because it displayed the correct result without apparent error when viewed there.
My understanding is that the data on a site at say 2 am on the first day of the year realtime is still in the meterological day of 31 December. So the idea is to not display the data as being on 1 January until after the new meterological day has become 1 Jan - i.e. after the rollover.
However, one would presume that the dayfile would not be posted to the webserver until after the rollover time anyway so it would seem this may fall into the category of "a solution looking for a problem". If this issue is of genuine concern then perhaps the better (more logical?) solution would be to extract the year from the last record in the dayfile rather than from the system. As we rollover at midnight, I have not really studied this in depth as it does not apply. I have reverted to the non-metdate code.
...use metdate directly from the CUtags file, or add it to the CU-Defs and use it from there...
Perhaps I should have been a bit more pedantic and expansive with my description.
Yes it would need to be added to the CUTags file as well as to the CU-Defs to be able to use it in CU-Defs, and, it would need to be available in the Cumulus version being run i.e. currently the Beta versions which it seems many are using and as noted elsewhere on this Forum. I had added notes to that effect in the script. However, no matter what I try I am unable to get metdate to work on the XAMPP test bed, so as noted above, for it to work the correct syntax would be required which I don't have and therefore I have removed it from the present code.
If I write it the way you suggest I get no data in the calendar.
If you write what?
$WX['metdate'] instead of $WX['$metdate'].
I do not understand exactly how the following process works...
Code: Select all
$data[$id] = $buf_arr[$dayfilecol] .'/'. $buf_arr[$dayfilecol2];
I do (and did) understand this was concatenating the two elements into the a single element - that is why it was done that way. With the help of XAMPP and your advice, the other parts of the code have been fixed and the page now appears to be error free. So this page is now entirely single columns and no colspan is required. The column/row highlighting also now works as expected which it never did with double columns.
See attached current versions of the scripts for review.