w34_util_wxsim.php serrvices all wxsim blocks/popups,
it is loaded by all wxsim scripts as the first include
and it then
=> compares the age of plaintext.txt versus the age of the cache arrays
==> if a new file arrived
===> it loads the parser
===> and saves Ken True’s arrays to the cache
==> if no new file arrived it loads the arrays from the cache
=> and returns the arrays to the calling script
Then the normal scripts can print what they need.
The WXSIM parser 'plaintext-parser.php' needs to be edited in order to provide the required information for its proper operation -
Yes it should be edited as it is the exact copy of Ken True's script. I stopped making small changes in someone else scripts as it always resulted in large problems
the 'w34_util_wxsim.php' template should not have be edited.
As w34_util_wxsim.php starts before the parser they both should now the exact location to check the filetime and to read the file
Note: On all the systems I have operating on my home/office server as well as my online server, no template, no data file is place in the root directory - for me, the root directory is 'sacred' and not to be used for any purposes except for an .htaccess routing file.
I agree with that 100%. That is why I have all my template/scripts in separate folders.
So I will make clear in the documentation that there are 2 locations to check.
As most wxsim users upload to the root, I leave the current relative addressing as is.
Thanks for finding that, it has been the same script form months.
The 24 hour clock can not have that problem. I will test tomorrow around noon.
If possible can you test this “enhanced” version.
Wim, rather than asking the user to check that the two locations be edited to point to the same location, could you not ask for the location of the ‘plaintext.txt’ data file in the main configuration template (as you ask for the path to the realtime data file) once the user has selected to use WXSIM when that product has been installed?
It looks good from my end for the most part. The only problem I find is that the nearby metar popup is not nearby. It’s Brussels. https://stillwaterweather.com/pws/index.php
Your ./jsondata/metar34.txt is not refreshed (an age of 12 hrs 16 min 14 seconds) so you probably not set the api, as @bitsostring also indicated
===
Your data file is entered as “https://stillwaterweather.com/wx/clientraw.txt”
That will result in multiple external file loads every minute.
Always try to use relative addressing for files on the same webserver.
You should change that to “…/wx/clientraw.txt”, that will use less overhead.
===
I see a new problem, thanks for that. #-o
The nws alerts do not nicely fit in the box.
I installed the July Beta version, and my WU charts quit working, so I uninstalled the July beta, and reinstalled the April version and the charts began working again.
As I reported in the April thread my charts began working about 05/07/19 and have been working 24/7 since then.
SORRY Wim,
False Alarm, I got it working, on my local test server. I’m sure it will work now on my live server.
I’m trying to get my Menu items set up on the July release of “w34_menu.php” file.
I mentioned before that I have some Radar links that will not open using the “w34_frames.php” file, so I just added my links to the “w34_menu.php” file.You can see on my live site (april version): https://www.loweprofile.com/pws/
But with the new “w34_menu.php” file I am having a hard time getting the links located correctly on the page. I have included the old code below (just one link), can you give me any advice where to enter my link code, so it looks like my April version?
If you want to include extra pages in the menu, you can use a standard iFrame script. Just check the
demo site where you find a few entries in the menu. The supporting script is w34_frames.php where
you setup the links to the extra page(s) you want to use.
You should not modify the w34_menu.php file but use the script which defines the extra menu entries.
I can not test the accuweather example as one needs to login for that.
So my example uses your nws forecast link and the [weatherdisplay link ](http://weatherdisplay link) from your current menu
This is line 49 in w34_frames.php (pws07 version)
# E X A M P L E S change them as you like
$frame = 'nwsforecast';
$frm_ttls[$frame] = 'NWS forecast'; // name in menu
$frm_src[$frame] = 'https://forecast.weather.gov/MapClick.php?lon=-93.55452001037594&lat=45.02110448314883#.XQCe29MzayF';
$frm_hgth[$frame] = 1500; //height
#
$frame = 'Weatherdisplay';
$frm_ttls[$frame] = 'Weatherdisplay'; // name in menu
$frm_src[$frame] = 'https://www.loweprofile.com/wx/';
$frm_hgth[$frame] = 1500; //height
#
The screenshot below shows the NWS page when loaded from the menu
I’m guessing that Accuweather has some code employed that inhibits embedding of their radar pages. Unfortunately they have the best radar images and we have very active weather here in Minnesota with nasty storms in the summer. Their Metro radar shows highly detailed images, not available anywhere else.
Even when I am logged in to Accuweather their pages will not load in the frame. I’ll do some further research and look at the errors that come up in Chrome development mode.