They're free, but use at your own risk
The scripts referenced here are used in the operation of this weather station, and may be freely copied and used to support your station. Please note that you use these scripts at your own risk. No warranty is expressed or implied. I accept no liability for any damages that may ensue from their use.
You will need to configure them for your own particular weather station website.
A RSS Feed is available to help keep you informed on updates to the scripts.
A Version History is available -- check back from time to time to see if there are updates to scripts you have downloaded earlier.
Announcements of version updates and new scripts are made on
and saratogaWXPHP Twitter account as they become available.
This page was updated
Monday, 19-Sep-2016 10:25 AM
PHP/AJAX Website Template Set - Maintaining your template website
With the ease of website maintenance provided by the included-file structure comes a few gotchas you need to keep in mind:
- A PHP error on any of the common included pages will make your website unviewable until you fix the error. Those pages are: Settings.php, Settings-weather.php, common.php, top.php, header.php, menubar.php, footer.php, ajax-gizmo.php and the weather tags file (testtags.php for Weather-Display, WXtags.php plus WX-defs.php for other weather software).
Moral: be careful to use correct PHP syntax when changing any PHP in the common files and make sure the files completely upload to your site.
- A XML syntax error in flyout-menu.xml (if the flyout-menu is enabled) will keep all wx...php pages from displaying until corrected.
Moral: use correct XML syntax when making changes to flyout-menu.xml
- A HTML syntax error in a common file (top.php, header.php, menubar.php ,and footer.php) will probably result in an unexpected appearance of your website pages.
Moral: validate any changes using the W3C validator (available via link at the bottom of each page) and correct any HTML errors.
The template and sample wx... pages all validate as XHTML 1.0-Transitional.
- A PHP error or HTML error on any wx... page will affect that page only. Use the first PHP error message as a starting point for what to fix the problem. Subsequent PHP errors may be the result of the first error reported, and clear up when the first error message cause is fixed.
- Be sure to edit all the .php pages using a PHP-aware HTML editor (or notepad) .. some editors (like older versions of Microsoft FrontPage) may modify the pages in unexpected ways and produce strange results. Not all editors may be capabible of displaying the local page in WYSIWIG format.
- Be sure to upload the PHP files to your website using FTP ASCII mode .. using FTP BINARY mode may cause failures. Most modern HTML editors with FTP built-in have this capability.
- As distributed, the template files are expected to be located in the document root of your website and the required subdirectories located below the document root. It is possible to use the templates from a subdirectory if the identical directory substructure is maintained and you continue to have URL and FILE relative addressing consistent (as it is now). You may be required to make additional changes that are not documented in the instructions if you wish to use the templates in a subdirectory.
- Make a local backup of your current website site before you start installation, and backup frequently as you work on installation/integration into your website. This is especially important if you have a website already and are going to convert to this included-file template .. read the installation information to prevent unwanted overwrites of your existing files.
Adding a new page to your site
You can easily add pages to your template set. The general process is:
- Make a copy of your wxnewpage.php and save it as a new page name. I suggest you use 'wx' as the first two characters in the name of the new page as it makes it easy to see what are 'presentation' pages on your site by looking at the directory listing, and prevents any interference with names of support scripts that may exist or be provided in the future. Make sure the copy has a .php extension so when uploaded, the PHP interpreter on your website will know to run the PHP code in the page.
- Edit the new page and insert the desired HTML markup and PHP code for the content.
- Save and upload the new page to your site.
- Validate the HTML on the new page by viewing on your website using your browser and clicking on the Valid XHTML link at the page bottom.
- Correct any XHTML errors found and repeat steps 3 and 4 until the page passes validation.
- Add the new file to your menu so it will show on all pages in the site.
For sites using the flyout menu,
Edit flyout-menu.xml and add the link as a new <item> entry, then upload the flyout-menu.xml to your website. The page should appear as a new link in your flyout menu. Keep in mind that an XML error in flyout-menu.xml will take your entire website offline until the XML error is fixed.
For sites NOT using the flyout menu,
Edit the menubar.php and add a new <li><a></a></li> entry to the list. Then upload the menubar.php and the page now appears on your website.
Using the $WX weather data on your pages
For the Cumulus, Meteohub, VWS and WeatherLink plugins, the weather tags are all loaded into an associative global array $WX so they can be used with PHP on any page in your website. These tags are the result of uploads through your weather software of the specially-constructed [WXsftw]tags.php file. Since each weather software has their own unique naming convention for weather tags, you will need to know what the tag names are for your software. You can use the following to display the names and contents of the tags files (assuming your tags file is uploaded to the document root of your website as recommended):
- Cumulus: view http://www.yourwebsite.com/CUtags.php?sce=dump (view sample)
- Meteobridge: view http://www.yourwebsite.com/MBtags.php?sce=dump (view sample)
- Meteohub: view http://www.yourwebsite.com/MHtags.php?sce=dump (view sample)
- VWS: view http://www.yourwebsite.com/VWStags.php?sce=dump (view sample)
- Weather-Display: view http://www.yourwebsite.com/testtags.php?sce=view (view sample)
- WeatherLink: view http://www.yourwebsite.com/WLtags.php?sce=dump (view sample)
- WeatherCat: view http://www.yourwebsite.com/WCTtags.php?sce=dump (view sample)
- wview: view http://www.yourwebsite.com/WVtags.php?sce=dump (view sample)
- WxSolution: view http://www.yourwebsite.com/WXStags.php?sce=dump (view sample)
You may wonder why Weather-Display uses a different tags name...it is to maintain compatibility with the prior version of the template sets which was Weather-Display specific. That, and Brian Hamilton (author of Weather-Display) had thoughtfully put in a one-checkbox configuration option to have Weather-Display upload the testtags.php file.
Say you wanted to add the display of the maximum temperature for today on your page. The different software have different names for that data:
- Cumulus: $WX['tempTH']
- Meteobridge: $WX['th0temp-dmax']
- Meteohub: $WX['day1_th0_tempmax_f'] (Note: Meteohub tags include sensor name and unit)
- VWS: $WX['vhi007']
- Weather-Display: $maxtemp
- WeatherLink: $WX['hiOutsideTemp']
- WeatherCat: $WX['STAT:TEMPERATURE:CURRENT']
- wview: $WX['outsideTemp']
- WxSolution: $WX['TC']
You can put that value on your page with by using:
- Cumulus: <?php print $WX['tempTH']; ?>
- Meteobridge: <?php print $WX['th0temp-dmax']; ?>
- Meteohub: <?php print $WX['day1_th0_tempmax_f']; ?>
- VWS: <?php print $WX['vhi007']; ?>
- Weather-Display: <?php print $maxtemp; ?>
- WeatherLink: <?php print $WX['hiOutsideTemp']; ?>
- WeatherCat: <?php print $WX['STAT:TEMPERATURE:CURRENT']; ?>
- wview: <?php print $WX['outsideTemp']; ?>
- WxSolution: <?php print $WX['TC']; ?>
The number of available tags varies greatly by weather software, and in order of fewest-tags to most-tags available the list is: WeatherSnoop, WeatherLink, wview, WxSolution, VWS, Meteohub, Cumulus, Weather-Display
I recommend you read the documentation that came with your weather software to learn about the available tags that might be used in your webpages.
The tags needed by the ajax-dashboard.php and ajax-gizmo.php are in Weather-Display format ($tagname), and the association (and sometimes computation) of those needed tags is contained in a [WXsftw]-defs.php file, so you can see which mapping is done by viewing in your browser:
- Cumulus: http://www.yourwebsite.com/CU-defs.php?sce=view (view sample)
- Meteobridge: http://www.yourwebsite.com/MB-defs.php?sce=view (view sample)
- Meteohub: http://www.yourwebsite.com/MH-defs.php?sce=view (view sample)
- VWS: http://www.yourwebsite.com/VWS-defs.php?sce=view (view sample)
- Weather-Display: (doesn't require a -defs file .. all necessary values are in testtags.php)
- WeatherLink: http://www.yourwebsite.com/WL-defs.php?sce=view (view sample)
- WeatherCat: http://www.yourwebsite.com/WCT-defs.php?sce=view (view sample)
- wview: http://www.yourwebsite.com/WV-defs.php?sce=view (view sample)
- WxSolution: http://www.yourwebsite.com/WXS-defs.php?sce=view (view sample)
Handy debugging tips
To see what is happening inside a wx.....php page, you can use the following arguments on the URL on your website:
- This will dump the final contents of the $SITE array as HTML comments on the page. Do a view-source in your browser after using this argument and the $SITE array contents will appear just under the end of the menubar like this small sample
This can be very helpful to see what $SITE values are to debug your site. Note that true/false variables are displayed with a blank as false and a 1 (one) as true. The output is also htmlentities() encoded to not mess up your page display while showing the values.
<!-- end of menubar -->
<!-- current settings
[charset] => ISO-8859-1
[lang] => en
[allowLanguageSelect] => 1
[useLanguageFlags] => 1
[languageSelectDropdown] => 1
[langavail] => Array
 => en
 => af
 => bg
 => dk
 => nl
 => fi
 => fr
 => de
 => el
 => hu
 => it
 => no
 => pl
 => pt
 => ro
 => es
 => se
[CSSscreen] => weather-screen-blue-narrow.css
[CSSprint] => weather-print-php.css
[allowThemeSwitch] => 1
- This will show on any wx.....php a list of the missing langlookup entries for language translation at the end of the page. Do a view-source on the page, and after the </html> line you can see something like:
<!-- missing langlookup entries for lang=en
langlookup|World Multilingual Website with PHP & AJAX|World Multilingual Website with PHP & AJAX|
langlookup|Sample Blank Page|Sample Blank Page|
langlookup|Local Weather Exchange Stations|Local Weather Exchange Stations|
langlookup|NOAA reports|NOAA reports|
langlookup|Status of weather software|Status of weather software|
8 entries. End of missing langlookup entries -->
You can copy the listed langlookup lines into your language-LL-local.txt file, provide the translation, and thereby fix the missing translation values.
- This will turn on verbose reporting from many of the built-in functions to show exactly what they are processing. It will also display (before the <doctype>) the loading/status of the language translation values. It will also show several PHP warning messages about 'Headers already sent', and you can ignore that .. just do a view-source on the page to see the debugging output as HTML comments interspersed throughout the page.
- This will display the $WX array contents based on the last upload from your weather software for the tags file. For Weather-Display use
http://www.yourwebsite.com/testtags.php?sce=view to see the contents.
- Most of the support scripts for forecasts, advisories, radar (etc) accept the ?sce=view argument to display their source.
Keep your scripts current the easy way
I know, maintenance of website scripts can be a real pain, particularly if you like to make modifications to scripts so they will display stuff as you like it. Well, the AJAX/PHP templates have been set up for tinkerers and out-of-the-box users, and both can minimize their labor required to keep the scripts up-to-date with current versions.
The files you are expected to modify to your liking are: Settings.php, Settings-weather.php, top.php, header.php, menubar.php, footer.php, flyout-menu.xml, wx...php, wx...html, language-*.txt, plaintext-parser-lang-*.txt and any new wx...php page you add to the site, or add-on scripts/pages from other authors.
The other scripts in the Base/Plugin distributions are considered support scripts and should remain as distributed. But.. it's all source code, and you're an informed citizen, so feel free to modify any of it to your liking and take on the burden of supporting what you modified.
Here are some tips to make your maintenance chore easier:
- Try to avoid making changes to the support scripts so you'll be able to just replace them when new versions come out (otherwise, you'll need to refit your mods into the new versions with each release).
- Use the http://www.yourwebsite.com/check-fetch-times.php?show=versions utility to check your installed scripts for current versions of the distributed Base/Plugin files [sample screenshot](this is available in V1.06+ of the check-fetch-times.php script).
- Use the Update Tool page to get a .ZIP file of needed updates based on a query (date, Base and Plugin). Dowload the .zip file generated and unzip it to a directory. You can examine the README file for recommendations on how to apply the updated files to your existing website.
You can also use an automated tool like the free Sourcegear Diff/Merge program to compare folders/files and apply merges to your existing template files easily.
How often should you check for updates? I'd recommend at least weekly (or any time a current script appears to be malfunctioning).
How can you find what the current updates are? You can subscribe to the Scripts RSS feed or to the SaratogaWXPHP Twitter feed or just view the Update Tool page which shows the last 20 updates for the templates without having to query.