Weather from OpenWeatherMap.org

[Jan Romero]

Sup.

FieldtypeOpenWeatherMap [GitHub]

This module fetches and stores current weather data from the OpenWeatherMap.org service and helps you manage icon markup. To limit requests, OpenWeatherMap.org’s JSON-response is cached in the database and only refreshed once the field is accessed and the cache has a certain age that you define.

The fieldtype is sadly not multilingual, but you can configure the language of the weather descriptions OpenWeatherMap.org provides you with. It would not be hard to make the output multilingual by referencing weather codes and translating them with ProcessWire’s built in tools.

You install FieldtypeOpenWeatherMap just like any other module, by placing the two files into ProcessWire’s modules directory. Once installed, you want to create a new field of the type OpenWeatherMap and assign it to a template. The template now has a text field that stores a city id.

In the field settings, you may configure how and when the data is requested. That is, the requested language, units (eg. °C/°F/K) and the cache duration.

The module does not provide you with built in icons or otherwise limits you to predefined markup (which I consider a good thing ). The icon in my example above is courtesy of Alessio Atzeni’s Meteocons (custom free license).

To make generating icon markup a little easier, you can configure your own markup snippets in the module configuration:

As you can see, in this example I’m using an icon font whose appearance is defined elsewhere in my CSS, but you’re free to put in image urls or just unicode entities or whatever. Rendering it is now quite simple. The following markup would result in something like the image above:

<?php
    $w = $city->weather;
    $temp = round($w->temperature);
?>

<p><?php echo "{$w->renderIcon()} {$w->description} at {$temp} °C"; ?></p>

<h2><?php echo $city->title; ?> <span class="ico-rightarrow"></span></h2> <!-- irrelevant line -->

The variable $w is now a WeatherData object that exposes the following properties:

json            //The raw JSON response from OWM
timestamp       //The time of the request
city_id         //The city id you entered in the admin

sunrise         //The time of sunrise
sunset          //The time of sunset

main            //The main weather name, e. g. “Rain”, in the configured language
description     //A slightly longer, more precise description like “occasional rain”
iconcode        //The internal icon code for this weather

temperature     //The temperature in the format you requested
min_temperature //...
max_temperature //…

wind_speed      //I believe the wind speed is also affected by the unit settings.

As well as the method renderIcon(), which you already know. If you access a WeatherData object as a string, you will get the city id. This is so that the city id will correctly appear in the admin page edit form. I should mention that there is some more information in the JSON, such as wind direction.

The module also exposes the method multiRequest(PageArray $pages, $fieldname). If you want to fetch data for a bunch of pages at the same time, you may want to use that so as to reduce unnecessary requests to the service. I haven’t really used this yet, so consider it experimental, I guess. As of now, this also disregards the cache freshness.

If you’re still reading, there’s a chance you might be interested in using this. Allow me to clarify that right now there is no support for forecasts or historical data (yet?). Sorry :>

Here’s the GitHub link: FieldtypeOpenWeatherMap.

[adrian]

Thanks for this - awesome. I have used OpenWeather, but not yet with PW and will need to in the next few weeks, so this will be a big timesaver.

Another nice set of icons that work seamlessly with OpenWeather are Skycons: http://darkskyapp.github.io/skycons/

[DaveP]

+1 for producing markup-agnostic output. I think most (all?) modules that generate markup should have at least the option of having them output an object rather than specific markup.

[pwired]

Thanks a lot for this. Reading your former posts,

we are glad to have you here at Processwire.

[kixe]

Super nice module. Awesome.
Got some Notices, just to no.
 

• Notice: Undefined variable: field in /site/modules/FieldtypeOpenWeatherMap/FieldtypeOpenWeatherMapConfig.php on line 16
• Notice: Trying to get property of non-object in /site/modules/FieldtypeOpenWeatherMap/FieldtypeOpenWeatherMapConfig.php on line 16

[Jan Romero]

Ah, good catch . The API key was a field setting before I put it into the module config. Wonder why I didn’t get that. I assume they’re only shown in debug mode?
 
Thanks for the kind words everyone. I appreciate it :)

[Nico Knoll]

Where is $city coming from? Do you added a hook to "city" or do you use something like $city = $modules->get('MarkupWeather'); $city->setId('1234'); ? (I would prefer the second one)

[Jan Romero]

Oh, nah, $city is just a page object and weather is a field. The sample was taken out of a foreach loop. To set the city id via API, you can do $page->weather = 12345 and save the page/field.

[bernhard]

just wanted to paste a reference to another weather module here:

I've asked a question about the differences there. Don't want to double-post, but as this information is related I think it's good to link both topics.

If you have any experiences with these two modules and can share them please answer my question in the linked topic, thanks.

[Leftfield]

Hi All,

Two questions please:
1. Is there a simple way to avoid allow_url_open with CURL because of security?
2. Field is recording every X hours in database, os it really gets long after some time - what's the fastest/best way to delete rows backwards?

[Jan Romero]

@Leftfield Uh, hey man, sorry, never saw your comment. I updated the module to use ProcessWire’s WireHttp, which should pick an appropriate way to request the data. I think it prefers cUrl and falls back to fopen. I also submitted it to the modules directory, because why not, I still run it in production…

Not sure what you mean in your second question. The module only stores the latest data it got as a cache. It won’t append records to the database. Every database row corresponds to a single page in your ProcessWire setup that uses the field.

[bernhard]

Hi @Jan Romero so is this module still usable? Do you have any links where the module is in action?

[Jan Romero]

@bernhard Hi, yeah, it seems to work perfectly fine for the humble job it does ?

It runs every couple of hours on Ennepe-Ruhr-Tourismus (it alternates between showing the weather and a tag line).

[bernhard]

Thx - haha, I did now see that you have a screenshot in the first post. Didn't realize that as it's a bit small and pixelated ? 

[Jan Romero]

The thing about the screenshot is that the module doesn’t generate markup unless you configure it to. You can specify the markup you want to output for each weather condition in the module settings according to OpenWeatherMap's icon codes. See the other screenshots for an example. It's a bit awkward ;‍)

[Leftfield]

9 hours ago, Jan Romero said:

@Leftfield Uh, hey man, sorry, never saw your comment. I updated the module to use ProcessWire’s WireHttp, which should pick an appropriate way to request the data. I think it prefers cUrl and falls back to fopen. I also submitted it to the modules directory, because why not, I still run it in production…

Not sure what you mean in your second question. The module only stores the latest data it got as a cache. It won’t append records to the database. Every database row corresponds to a single page in your ProcessWire setup that uses the field.

Thanks for the answer!!!!

Quote

2. Field is recording every X hours in database, os it really gets long after some time - what's the fastest/best way to delete rows backwards?

It records queries in database. It didnt delete old ones. At least when I made the question

[Jan Romero]

@Leftfield Mh, that seems strange? It should simply update the row. A row will look like this, where the second column is “data” and contains the latest result from OpenWeatherMap and the last column is “timestamp” and remembers when the result was obtained:

2287

{"coord":{"lon":-55.1700000000000017053025658242404460906982421875,"lat":5.87000000000000010658141036401502788066864013671875},"sys":{"country":"SR","timezone":-10800,"sunrise":1587547818,"sunset":1587592050},"weather":[{"id":802,"main":"Clouds","description":"M\u00e4\u00dfig bew\u00f6lkt","icon":"03n"}],"main":{"temp":23.3299999999999982946974341757595539093017578125,"feels_like":25.0799999999999982946974341757595539093017578125,"temp_min":23.3299999999999982946974341757595539093017578125,"temp_max":23.3299999999999982946974341757595539093017578125,"pressure":1010,"humidity":93},"wind":{"speed":4.32000000000000028421709430404007434844970703125,"deg":53},"clouds":{"all":34},"dt":1587543285,"id":3383329,"name":"Distrikt Paramaribo"}

3383329

2020-04-22 11:12:14

That’s from the table “field_weather” (depending on what you called the field in your setup). Do you mean a different table, maybe?

[Leftfield]

@Jan Romero no. It made row for every new data. Tested now, it is OK.