Cloudbase CU script ex Bashewa

[gluepack]

It also seems you have not changed any settings to your local lat/long or metar etc.

You override the $SITE variables? I didn't think you did.

I see you also changed the images folder from cloudbase to ../images/ That may well be part of the issue as it probably should be ./images/ - only one leading '.' which means relative to the current location (of the script). The two '..' send the processing off to the very root of the website of the hosting system, not what you usually want.

Lol, it is because they are in the images folder off the root directory. And, yes it is often what I want. Would the tests work or do you uses hard coded images? I doubt it.

You seem to be using something else as the error is showing uom=I which is for imperial and the height is in feet. However your station will be supplying (I presume) metric.

So, what would cause that to happen then as the uom* variables are set appropriately (and the Ajax equivalents are ok too)? Everything else on the site (appears to) works.

As advised previously the command line I use in ajax-dashboard is in the form of;
<img src="cloudbase.php" alt="cloudbase" width="100" height="200" />

I use <?php echo '<img src="'.$cloudbase.'?uom='.$uomCld.'" alt="'.$cldTxt.'" title="'.$cldTxt.'" style="width: 100px; height: 200px; border: none;" />'; ?> in the http://www.jerbils.info/saratoga/wxtestit.php, as per instructions, and all the tests seem to work with http://jerbils.info/saratoga/cloudbase.php. Surely, they're not hard-coded results of the test?

[gluepack]

Ok, I can't diagnose the code but I have done some testing. The results might not help at all but, at least it appears that the image is (in theory) being created ok, it is just not being displayed..

In Chrome, F12, [url]html://www.jerbils.info/wxtestit.php[/url] shows the following generated...

<img src="cloudbase.php?uom=I" alt="Cloud Base @ 1416 feet (ASL)" title="Cloud Base @ 1416 feet (ASL)" style="width: 100px; height: 200px; border: none;">

and what shows is a rectangle 100x200 in the page with the "broken image" icon in the center.
If you right click and select "open image in new tab" the url http://www.jerbils.info/saratoga/cloudbase.php?uom=I is opened in a new tab and the broken image icon is displayed.

So, I made some mods under F12 to change the statement to...

<img src="cloudbase.php?uom=m&html=1" alt="Cloud Base @ 1416 feet (ASL)" title="Cloud Base @ 1416 feet (ASL)" style="width: 100px; height: 200px; border: none;">

I don't know, if doing so, whether you would expect the original page to change (it does when you change other items, like style info.) but it doesn't.
Now, of course?, if you right click and select "open image in new tab" the url http://www.jerbils.info/saratoga/cloudb ... m=m&html=1 is opened in a new tab and the info is displayed as expected for the test "uom=m&html=1".
Also, if you right click the box with the broken image icon and "Save image as...", a jpg is downloaded but it is corrupted. That is because it isn't an image at all, it is a set of html code associated with the output of the test "uom=m&html=1".

If I modify the statement to read....

<img src="cloudbase.php?uom=m" alt="Cloud Base @ 1416 feet (ASL)" title="Cloud Base @ 1416 feet (ASL)" style="width: 100px; height: 200px; border: none;">

and right click the box with the broken image icon and "Save image as..." a jpg is downloaded and displays fine.

So, the image is being created fine (and, of course, I didn't need to do any of that testing as the proof of it is the presence of the cloudbase.jpg in the (saratoga) folder), it is just not being displayed (except when embedded in a piece of html, as in the "uom=m&html=1" test).

Googling the problem seems to imply that the main culprit is white space prior to and post the PHP open and close (<?php ?>) but it is obvious from the content of cloudbase.php that the authors were aware of this. Any other ideas?

[BCJKiwi]

It also seems you have not changed any settings to your local lat/long or metar etc.

You override the $SITE variables? I didn't think you did.

I don't understand what you mean.
the $SITE vars (if set) will override anything set above in the script - this is standard practise in the Saratoga Scripts.

I see you also changed the images folder from cloudbase to ../images/ That may well be part of the issue as it probably should be ./images/ - only one leading '.' which means relative to the current location (of the script). The two '..' send the processing off to the very root of the website of the hosting system, not what you usually want.

Lol, it is because they are in the images folder off the root directory. And, yes it is often what I want. Would the tests work or do you uses hard coded images? I doubt it.

Again, the standard practise is that all references are relative to the script location. Also one would normally place the images folder immediately under the folder the scripts are in - the scripts folder is not the system root. Accordingly './' or nothing refers to the current location. '../' refers the very root of the system in which webserver is running. Generally your script will be found but not always. It is inefficient and not recommended. If of course you really do have the images folder off the root of your server system and not immediately under the scripts folder than you will need the ../

You seem to be using something else as the error is showing uom=I which is for imperial and the height is in feet. However your station will be supplying (I presume) metric.

So, what would cause that to happen then as the uom* variables are set appropriately (and the Ajax equivalents are ok too)? Everything else on the site (appears to) works.

As advised previously the command line I use in ajax-dashboard is in the form of;
<img src="cloudbase.php" alt="cloudbase" width="100" height="200" />

I use <?php echo '<img src="'.$cloudbase.'?uom='.$uomCld.'" alt="'.$cldTxt.'" title="'.$cldTxt.'" style="width: 100px; height: 200px; border: none;" />'; ?> in the http://www.jerbils.info/saratoga/wxtestit.php, as per instructions, and all the tests seem to work with http://jerbils.info/saratoga/cloudbase.php. Surely, they're not hard-coded results of the test?

What happens if you use the command line form that I suggested?

[BCJKiwi]

Googling the problem seems to imply that the main culprit is white space prior to and post the PHP open and close (<?php ?>) but it is obvious from the content of cloudbase.php that the authors were aware of this. Any other ideas?

Indeed there does appear to be some junk or white space before the <?php This is not in the files I posted so presumably is either a corruption or has been introduced through editing at some point.
The script is VERY CLEAR;

<?php
#...YOU MUST NOT HAVE ANY SPACES IN FRONT OF THIS PHP OPENING TAG
#...Nor should any of the files used with this script have any
# spaces either before or after the opening/closing PHP tags

So remove the white space.
Also I see you are using the ...ORG version which is defaulting to Imperial. Is that what you want?

I suggest you try the ...SA version which is configured for metric, check there is no junk before the ?<php and see if that is any better. Start simple and leave out all the complications you have introduced in the calling script. If it works then you could add them later.

[BCJKiwi]

I see the script has been downloaded 27 times so far.
Would be interested to know how many of you have it working and how many of you are having trouble.
Thanks

[Werk_AG]

I installed it yesterday in a Saratoga Template, and it seems to be working fine. Follow instructions, some work on the template, and it works first try. Don't have changed anything on the script.

Thanks for the script

[gluepack]

I don't understand what you mean.

Obviously not.

The $SITE variables are set fine. If there is a problem then they are being overridden for some reason.

If of course you really do have the images folder off the root of your server system and not immediately under the scripts folder than you will need the ../

Thanks, I know that. That is why I use it.

What happens if you use the command line form that I suggested?

The tests work. The code works, in as much as the cloudbase.jpg file is being created correctly, it is just not being displayed.

Indeed there does appear to be some junk or white space before the <?php This is not in the files I posted so presumably is either a corruption or has been introduced through editing at some point.

Don't know which file you are looking at. There is no (obvious) junk or white space prior to <?php in the cloudbase.php that I am using.

Also I see you are using the ...ORG version which is defaulting to Imperial. Is that what you want?

Strange question when my $SITE variables are all set to metric. Look at any other page on the website.

I repeat, all the tests work and the cloudbase.jpg is being created, it is just not being displayed.

Don't worry yourself about it. I'll figure it out.

[gluepack]

OK, resolved.....

I am using Notepad to edit the cloudbase.php file locally. In fact, currently, I am accessing files from my desktop system on my laptop and saving them back. I then copy the file(s) to my laptop and then WinSCP to my website (it may sound long winded but a) it keeps them up to date on my laptop as well and b) winscp will not allow me to copy from my desktop networked drive when on my laptop).

Despite the fact that there are no blanks (non-displayable characters) preceding the <? or following the ?> at the end of the file, when viewing it in Notepad (and attempting to remove anything there that might be non-displayable), when the file ends up on my website it has a trailing blank/non-displayable character.

Editing it via WinSCP on the website shows that there is a trailing blank/non-displayable character and removing it and saving it back causes cloudbase.php to work when invoked from within a webpage.

And, fwiw, when I copy the original two cloudbase (SA/ORG) php files to my website the WinSCP (at least) editor shows a trailing blank/non-displayable character on both of them. Also, editing them (via WinSCP) on my system shows the same thing. So, unless WinSCP is generating it, I guess it is there in the original php files (oh, unless WinRAR is putting it there when unpacking). If I had a better editor to hand I would try it.


Update...
ok, curious, all I can think of is it is the eof marker. Even using Notepad++, nothing shows up after the ?> but, using the built in WinSCP editor, looking at the file on both my system and the web site there is a character following the ?> and removing it causes cloudbase.php images to be displayed when invoked from another php file.
Even removing the last part of the file back to the end of #...YOU MUST NOT HAVE ANY SPACES AFTER THIS PHP CLOSING TAG
(i.e. no ?> ) causes it to work.
I have seen various comments while Googling that suggest ?> is more trouble than it is worth.

Anyway, now I have modified it slightly and incorporated it into my weather site home page. I did work on further modifications to have it produce the image plus just the "conditions" to fill up the white space below it but, although I have made the appropriate mods to produce the result independently, I can't figure out how to have it produce the appropriate html inline.

[kapo]

Hi
I installed this fine script for Cumulus, after I finally found it. I have seen it working in various Saratoga templates and wondered where could I find that script... And now that script appeared here. I installed it at once. And it started to work at once!! I did a little bit changes in font colors etc. but this very fine script started to work at same time I finished the installation!! And it works till... Thank You very much about this script. I installed that fine thermometer with those beautiful colors too, and it works perfectly also!!! Thank You about that script also!!

[BCJKiwi]

Thanks Werk_AG & kapo - nice to get some positive feedback.

@ Gluepack

I have looked carefully at the various files.
The ..SA posted does have a blank line after the closing ?>
However many of these scripts have that and it does not seem to cause any issues however I usually remove it when I notice it.

If your script works with no closing ?> but won't with it then it suggests some other issue.
The script should run self contained and in that form the php opening <?php should be matched by the closing ?>. However yours does run without I so the php closer must be coming from elsewhere or being supplied by the webserver.

I notice the validator is showing a number of errors on your site which may or may not have anything to do with the issues.

Enjoy.

[gluepack]

I notice the validator is showing a number of errors on your site which may or may not have anything to do with the issues.

Lol, you don't need a validator to know that there are things wrong with my site. I implement the same bad practices that many of the people that I copy from use

Also, you can never be too smart to ignore the rest of the industry.

However many of these scripts have that and it does not seem to cause any issues however I usually remove it when I notice it.
If your script works with no closing ?> but won't with it then it suggests some other issue.
The script should run self contained and in that form the php opening <?php should be matched by the closing ?>.

Well a) I didn't say "script works with no closing ?> but won't with it", that is your interpretation and b) Google any phrase that suggests no ?> and you will see that not only does the PHP end tag cause many problems, specifically due to the fact that additional material following it is common and does cause problems, but that it is unnecessary too.

However yours does run without I so the php closer must be coming from elsewhere or being supplied by the webserver.

The physical end of file terminates php code.

Zend are the people (largely) responsible for PHP and their manual says...

The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include() or require(), so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.

Thanks anyway for going to the trouble of modifying someone else's code to produce what is a reasonable result.

[saratogaWX]

The secret to getting an image generation script working without having the dreaded broken-image displayed is to have no characters before the <?php in the start of the file, and no characters after the ending ?> (or end of file)

If PHP detects a character not enclosed by the <?php ... ?>, then it will helpfully emit a header that destroys the image created by the script. It also applies to any file you happen to include() in the script. AFAIK, only the thermometer.php, cloudbase.php and the sparkline graphics PHP files have this sensitivity.

If the broken image persists, then using the command line

GET http://.....

and viewing the output can be helpful is seeing what is being returned (PHP error messages, etc) and help you to fix the issue(s).

Best regards,
Ken

[gluepack]

You explain it so much better than I. That is why you are a moderator, I guess

Anyway, I have modified cloudbase.php (as cloudbasetxt.php) to force html mode and output (only) the "conditions" underneath the image, to fill up the white space that was generated due to the size of the image and my placement of it. I had also modified the cloud temperature to include a decimal place, increase font size and include a @ (so, for me at least, it was more obvious what the temperature referred to).

Once I figured out that the "exit;" was exiting more than just the cloudbase php file, lol, it worked ok. Now, to think about making the whole dashboard look a bit more aesthetically pleasing.

[Mark14]

Cloudbase height comes from Cumulus, not Metar.

So I can't set it to take data about cloudbase from METAR?


I have some doubts about the settings for the METAR station. In cloudbase.php file (ORG) (http://pogodaslesin.byethost11.com/cloudbase.php) I have:

Code: Select all

$metarICAO        = 'EPPO'; 

the same station code is in my template http://pogodaslesin.byethost11.com/wxindex.php?lang=en#

Nevertheless there are moments when the weather conditions are different between them, eg. in my city whole day is clear weather (sunny without clouds) but at the same time cloudbase.php shows a drizzle. It's weird.

I looked at the other pages with the script and the weather conditions are the same. Moreover, I created my own file with translation and sometimes the text is in English, French and at times in Polish...

[gluepack]

I'm inclined to agree with you Mark.

I changed it so it is getting conditions from METAR, my local airport 20 mins away, as per..

$metarICAO = 'LBWN';
and
$useMetarAtNight = true; // always use METAR at night time for determinig clouds
$onlyUseMetar = true; // always use METAR for determinig clouds

and it says...
Drizzle, showers, showery, becoming less settled (it now says Rain, thunderstorm, occasional precipitation, worsening)
with an 1186m cloud cover
when there isn't a cloud in the sky and I just saw an airplane quite clearly going overhead that my airplane app. says is at 11582m

and their METAR "report" says Summary: Clear - Visibility: greater than 10 km