I checked a few rest-sites 2.6 and 2.7) and they show wind correctly (windspeed-arrow-direction)
As a test you could check if the gadget works OK when switching back to the yowindow site.
Change line 67 in the settings in wsDashYowindow.php from

$use_yow_site           = false;

to

$use_yow_site           = true;

is the console for VP2 likely to be an option in the future as the current option I tried using Saratoga template gives error 500 and I do not now why had to remove from menu [console test link](http://www.hc-iom.co.uk/WD-AJAX/console.php)

You can add any script in the template using the new-page.php and or an iframe. As you are using WD the standard script console script works OK as it uses clientraw to get the 24hour data. http://www.meteosauwerd.nl/weather/index.php?p=9999&lang=nl#data-area http://www.weerstation-wilsele.be/index.php?p=9999 It takes some tweaking and customizing, but there are dozens of them around.

I am working on an adapted console script for release 2.8 December which should work for all 12 supported weatherprograms.

has anybody else had problems with the blitzortung.org site today slow to download images and site not accessible Harold

Yesterday it was slow, sometimes the public blitzortung can be that way. Wim

Hi Wim
changed line 67 to true and uploaded to main site and the wind info is shown on the site now
have I missed something when setting 2.7 up, version 2.6 is set to false and works ok

may look into the console when I get back from my brothers but more likely will wait till 2.8 comes out

thanks
Harold

one thing I have tried with regards the console on the main site on my existing setup was change the *.js names which had additional “.” in to “_” i.e. jquery.davconsoleCW.js to jquery_davconsoleCW.js as my host is running window server 2008 but that sadly still gave 500 error, as I have had issues with too many “.” in file names before. I suspect there is something in the jquery.davconsoleCW.js it does not like even after renaming it so I will wait till your 2.8 version is out in December and try that. (my test unit is linux based and it works ok on that)

Harold

Thank you for sharing your excellent work Wim

I’m testing 2.7, and I have the same problem as Harold wth records.

Webpage shows:

Station record:

29,5

Max/min temps for today/yesterday/month and year have a day/month next to the temp so they are for this complete uear.

Last year max/min temp has also a time as it is the high/low for same day (august 5 but last year).

Station max/min records are also for the same day, but for any year in the past but grom your own weathersdata, so there is the relevant year next to it.

The all-time data from the uploaded tags arer used for the history page and do not appear on the dashboard.

===
Records today are the "official’ max/min temps for your area from either metar or any other source WU get thats data from
Normals today com from the same source and are the normal max/min temperatures this time of year for your area.

I could add some extra space or a line between stations data and the two lines which are introduced to compare stations data with.

And change the text (language file) for
“Last year” to “Today-last year”
“Station record” to “Station any year”

But you can already change that yourself to make it cleare for the visitors and yourself.

Wim

---

Thanks for clearing this out Wim - now I get it

My iPad and iPhone is not so happy with the 2.7 - it’s not adapted to the screen without zooming?

I’ve searched in your wiki without any solution.

I can not duplicate this using the URL of your site. http://www.vejrstationen.dk/weather27/

I used 2 iPads with three browsers. Safari displays correctly with small background left and right in “width” position and no extra background in tall position… Safari is the only browser which understands the special iPad html at the start of the page.

Chrome enlarges and uses the complete width of the screen both in vertical or horizontal mode, but the “gototop” button is misaligned. That is a known “problem” width adapting to use full screen width. The JavaScript does not know chrome changed the display size so it is still displaying the button were it was, just before chrome is resizing to use the complete width.

Puffin uses whole screen but is slightly miscalculating and hiding small area at right. You have to manually resize and the same JavaScript /“gototop” misplacement error occurs then.

But that is nothing compared to the errors you are having. What browser are you using?
The background is not displayed in your image and the full height of the page is shown. Very odd.

Wim

I’m using Safari, and I’ve also tried with Chrome on my iPad Air 2. My wife’s iPad 4 has the same behavior.

I suspect it’s the iOS 9 beta that are causing the trouble.

Are you still on the iOS 8?

You are barking at the wrong tree.

I support a template for 12 different weather-programs.
I have to make sure that the resulting HTML-5 output works acceptable on most recent browsers on most used platforms.
I can and will not use and will not support non-standard or non-public versions of either webservers or the OS for pc or tablet.

A beta is to test and help the developer, in your case apple, which you should contact with these errors and inconsistencies.
After it goes public I will install a new version of IOS to see if they changed the browser.

You already detected that is is probably in the undelying OS as both Safari and Chrome have this behavior.

Please next-time mention that YOU have a problem with YOUR non-standard version of anything, so that this guy does not have to test 2 different ipads with 3 different browsers and waste time which could have used to help others.

If I sound more then a little irritated or p****f , that is correct.

Wim

I’ve solved another one - the Steelseries wind gauge pop up info “Bearing: 359 (undefined)” (when using MeteoHub).
I found out that the value 359 is “hardcoded” and the function getord doesn’t like it.

The solution - supply a real value:

In the file tags.mh.html (on MeteoHub) I added the line

|gustMaxTodayDir|[day1_wind0_gustspeedmax_deg:--]|!

in the wind section.

In the file tagsMH.php (weather27/scriptsMH/) I added the line

$ws['gustMaxTodayDir']   =                   $wx['gustMaxTodayDir']*1.0;

in the wind section.

In the file wsAjaxDataLoad_v3.php (weather27/) I relaced this

$arrOut['bearingTM']	= '359';

with this

$arrOut['bearingTM']	= $ws['gustMaxTodayDir'];

And now it’s showing the correct bearing of the max. gust today

Dear Wim

I’m sorry if I wasted your time, but since the version 2.6 worked with IOS 9 beta, I didn’t suspect this to cause the problem.

Also I didn’t have problems with other webpages and IOS 9 at all - so that’s why I didn’t think about it.

You sound irritated yes, but anyway please accept my apologies, for wasting your time.

I know you are working very hard for free - I hope more people would give you a donation, for sharing your great work!

The only major difference in javascript which could cause this is the use of floating.js to go to the top of the page.
It is used in your 2.7 version but not in your 2.6 version.
Safari and other browsers have problems when resizing the page and placing the gototop marker at the correct position already in the current OS version.

Could you test version 2.7 by switching it off?

$SITE['floatTop']               =  [color=red]'';  [/color]  #  './_widgets/float_top.php';   

Your settings are protected so I can not check, but somewhere close to line 70 in wsSettingsUser.php

Wim

No change by switching it off Wim…

But the funny thing is, that weerstation-wilsele.be with version 2.6a does not load correct neither on my iPad, but my old 2.6a does (www.vejrstationen.dk/weather2) ?

weather-template.nl with 2.7 beta - is working correct

weerstationalkmaarcentrum.nl with 2.7a - not working correct

wetterstationdortmund.de with 2.7a - not working correct

gand.dk with 2.7a - not working correct correct

Maybe it’s something with the items selected to be shown on the frontpage - I’ll try to do some testing here.

I’ll let you know, if I find a red line…

Thanks for helping, and again I’m sorry

Change lines 138 - 141 from

$htmlTxt.= '	<meta name="description" content="'.$titleOfPage.'" />'.PHP_EOL;
$htmlTxt.= '	<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="viewport" content="user-scalable=yes,maximum-scale=2,height=device-height">'.PHP_EOL;
$htmlTxt.= '	<meta http-equiv="Content-Type" content="text/html; charset='.strtoupper($SITE['charset']).'"/>'.PHP_EOL;

to

$htmlTxt.= '	<meta name="description" content="'.$titleOfPage.'" />'.PHP_EOL;
$htmlTxt.= '	<meta name="apple-mobile-web-app-capable" content="yes" />'.PHP_EOL;
#$htmlTxt.= '	<meta name="viewport" content="user-scalable=yes,maximum-scale=2,height=device-height">'.PHP_EOL;
$htmlTxt.= '	<meta http-equiv="Content-Type" content="text/html; charset='.strtoupper($SITE['charset']).'"/>'.PHP_EOL;

I think after some test, that the viewport setting is the cause of the problem.
To busy tonight, will see tomorrow if that is a correct deduction and what typo or error in that line is causing this.

Wim

You know what - it totally cured the problem

Page is loading flawless on my i devices now.

The only very little problem I can spot, is that yowindow doesn’t switch to yr metrogram in webversion on iPhone - works perfectly on iPad and also Windows phone.

As you say - you support so many platforms, and it’s like impossible to make the page and all scripts work will all devices.

So for me - don’t spend time fixing that - maybe it will solve itself with public release of IOS 9

Thanks for your help Wim

Hello Wim…

I am helping set up the Leuven Templates for a Friend in York, Pennsylvania USA and he has the newest downloaded version 2.7

I cant seem to get the GAUGES at top to work, keeps saying file corrupted. The data below in dashboard is working. any help or idea’s why the gauges are not working would be Appreciatted.

site is here:

http://www.m82a1.us/weather27

just created a few days ago.

this is the settings I have in the file:

COMPATIBILLITY for WeatherDisplay / consoleWD users

set to true ONLY if it is ABSOLUTELY necessary to use testtags.php from Saratoga or Leuven

#---------------------------------------------------------------------------
$SITE[‘use_testtags’] = true;
#---------------------------------------------------------------------------

IMPORTANT will you be uploading to the default upload folder (uploadXX) where xx is the short code for your weather program

#---------------------------------------------------------------------------

$SITE[‘standard_upload’]= false;

If you do not want or are not able to upload to the default folder set the correct upload folder here

$SITE[‘uploadDir’] = ‘…/’; // ##### example for upload to root
$SITE[‘clientrawDir’] = ‘…/’;
$SITE[‘graphImageDir’] = ‘…/’;

…and both the clientraw and testtags are uploaded to the root directory of server

Thanks…Chris

@Chis: I think it would help Wim if you post the URL

ooopps…

yes you are right Niko…I forgot to put URL in post above. I just edited that post above and added the URL to it.

…Chris

P.S. Thanks Niko

Where is the customclientraw.txt ?

The gauges at the top come from this script: http://www.m82a1.us/weather27/ws_gauge_frame.php?lang=en&wp=WD
The data is loaded via this URL: http://www.m82a1.us/weather27/ws_realtime.php?wp=WD?lang=en
Response is the well-known but not liked error message:

<b>Warning</b>:  Cannot modify header information - headers already sent by 
(output started at /home/m82a1pa/public_html/weather27/_my_texts/wsUserSettings.php:1)
 in <b>/home/m82a1pa/public_html/weather27/wsAjaxDataLoad_v3.php</b> on line <b>210</b>

There are characters before the “start php” < ? php so they are considered HTML and sent to the browser. Those characters are the BOM-characters!
The file is either modified with notepad.exe which automatically adds those characters, or the file is saved with the wrong characterset.

Opening the file in notepad++ and using a save as or selectiong at the bottom right UTF-8 WITHOUT BOM will remove this problem.

Wim