AndyWalmsley

Hi,

This does seem like something else is causing the plugin to behave in this way as even if the name of the spot is incorrect once it shouldn’t be creating multiple drafts with the same name, what caching plugin are you using, I will try and do some testing to find out if that is the cause.

In the meantime, what happens when using the ID of the Spot instead of the name? To get the ID go to your Spots list and in the URL of the Spot you are trying to show will have a numerical ID .

Unfortunately not.

I should have a bit of time to look at this issue today and/or tomorrow so will hopefully be able to find a solution.

Hi Ivan,

In the plugins current state; no. I will look into adding it an update when I get the chance.

Thanks for the suggestion.

Sorry for taking so long on this, I’ve only just had the chance to look into it.

In the city field on the widget settings are just entering Charleston or are you putting in the state code as well? As just city work much better, also try using the city ID 4235668 to see if that works better.

Hi Clifford,

The screenshots actually show the difference in the thumbnail preview at the top right of the image, in #1 the preview shows too much of the left side of the picture showing only about half of the face, whereas in #2 the preview shows the whole face with none of the background.

I will see if we can make it at all clearer what these screenshots are showing when I get time.

Thanks for the feedback.

Hi surfbird0713,

I’ve not had any other reports of this happening, what city, country combination are you searching for? It may be a problem with that and if you can give where you are searching for, I will investigate into why it is happening.

Hi soreese,

Unfortunately as the weather is provided by OpenWeatherMap we don’t have any control over what is returned and so it may occasionally return incorrect weather.

When using the CityID 4167583 for Palm Springs I get 77 degrees at Fri, 01 May 2015 13:48:04 GMT.

If the weather returned doesn’t get any more accurate, there is unfortunately nothing we can do about it.

Sorry for the inconvenience.

Hi, sorry for the slightly delayed reply.

The weather returned to our widget comes from OpenWeatherMap which is out of our control so we can’t guarantee the accuracy of the weather.

Also, the data in the weather widget is cached for however long you have set the frequency parameter to (defaults to 60 minutes) so you could be seeing weather from up to an hour ago, as right now, your site is showing the weather to be 48F while weather.com is also showing 48F.

If it ever seems vastly different from what you expect, you can try changing one of the settings and then refreshing as that clears the current data and does a fresh search which would hopefully return the correct weather.

Hi jakubwojcik,

This is a known issue as mentioned here:
https://www.ads-software.com/plugins/interconnect-it-weather-widget/other_notes/
It is caused by the transients that are storing the data have the same ID because the shortcode ID uses the post id.

I am trying to find a good way to fix this but currently the only way I can find to fix it could fill up your database quite substantially with Transients, so I will keep looking and trying out whatever solutions I can find and hopefully get it fixed as soon as possible.

In the meantime, it works in widget spaces if it is possible for one or both of the widgets to go in a widget space. If not then I apologise for the issue and will try and fix it as soon as possible.

As a side not; if you are using city ID then you do not need to use the country parameter, OpenWeatherMap will return both city and country from the ID.

The updates in version 2.4.4 should have fixed this issue.

Let me know if you are still getting errors or if there are any other problems.

With the updates to version 2.4.4 this should now be fixed and appears to be working when viewing https://www.chrishanley.com.

Let me know if this problem persists or if you have any others.

It will be to do with how the data is stored when using shortcodes.

It’s now using WordPress Transients so the data gets stored in the database for as long as the frequency parameter is set, or until there is a change to the settings. So changing browsers shouldn’t change anything as it’s getting the data from the database.

To check when the settings have changed using the shortcode is just goes by when the post/page was last updated, or when the data was last updated due to it timing out depending on which was latest.

That still doesn’t really explain why it was displaying Orosei in the first place unless there was another weather transient with that data stored in it.

That shortcode is working fine for me.

Try changing something on the post/page and refreshing again, updating the post/page when using shortcode should force the data to be cleared so that settings can be updated.

Let me know if that doesn’t fix it.

It shouldn’t really make much difference but if one seems to work better then stick with that one. The only difference I noticed between GB and UK is the country name returns fully if using UK while GB only returns ‘Gb’.

When I used the name Henley on Thames though OpenWeatherMap would occasionally return weather for Birmingham. Using Henley-on-Thames worked better but ID always returned the right place.

So, I’ve found that ID works best and if using ID then country will only affect the display of country name.

Also, there is currently a slight problem with the weather not updating when updating shortcodes, this is going to be updated very soon, I’m just doing a couple more tests to make sure everything works.

The problem is happening because of the inconsistency of the api calls.
So if there is no problem getting the weather back quickly from OpenWeatherMap then everything displays fine, if it is a bit slow or for whatever reason can’t get any data back then it shows an error.

I’m currently working on getting the plugin to be more reliable and also to not just display an error saying there is a problem with the city, as that was very rarely the actual problem and has caused frustration with some users getting a useless error message when the city they are searching for quite obviously exists.