WeatherIcon/ allow_url_fopen?

Tremendously horrible? I beg to differ. Don’t believe the hype you hear on their support forums. Remember 90% of the individuals visiting their support forums are visiting because they have something to complain about. The same goes for the WordPress forums. Personally, I have had no problems with DreamHost, and know many who have also had no problems (However, there is a problem with the server “zorg”. If you’re on that, request a move ASAP.). Now, the decision to disable allow_url_fopen was, IMO, a smart move. allow_url_fopen allows PHP scripts to be loaded from remote URLs. It’s insecure and can leave you open to malicious scripts. In fact, according to DH’s last report, quite a few support requests were due to exploits of allow_url_fopen, and the drop in their support que proves it.

Now, on to your question. After searching through the files for WeatherIcon v2, it appears that it will not be affected by disabling allow_url_fopen.

Wow, thanks for putting my mind at ease! My personal experience with Dreamhost has been horrible. Since moving to them in late January, I’ve had to file nine (9!) service requests due to outage. The customer service is top-notch, but dealing with them so often isn’t fun. In the last seven years of hosting with other companies, including 1&1, I’ve never had to report that my site was down, not even once. I just assumed that once they identified the server I was on, they would fix it, or move me. They refused.

Oh well, thanks again for helping me!

jennmiller,

I can understand your frustration if you moved to Dreamhost in January. They *have* been having problems of late. I have seen this before with them (first started hosting with Dreamhost in mid 1997), but they are, on the whole, an excellent and responsive host. I think the problems you are having are temporary in nature, and I really believe that, if you can stick it out, you will also experience the best they have to offer.

macmanx,
As for the allow_url_fopen setting change, I’m not quite that the decrease in the support que is related to the change; at least on all my servers (about 20 domains) allow_url_fropen is still reported by phpinfo as being “On”. I know that they announced they would set it to off on March 29, but it has not happened yet on my end. I’m still waiting for them to do it so I can thoroughly test all my scripts.

I’m not real “up to date” on all this, and am wondering if running PHP as CGI is not effected. Could this explain why phpinfo on my PHP-CGI domains still reports the setting as on?

To bring this thread back to life: I upgraded to WP 1.5.1.3 the other day on one of my blogs, and now today I ditched WeatherIcon 2.0 … it does use (fopen) and the plugin was throwing an error a mile wide on the side of my front page on top on any call to the plugin, about “fopen”. Open the weathericon.php plugin file and you can find two “fopen” items. It’s connected with opening the meta cache file. That’s exactly the trouble with it. I deactivated my plugin first, then deleted it, redownloaded it, uploaded it again, activated it, had three different stations called, and all did the same thing: drew in data, but there was no file ever created in the cache folder, as it was before.

I’ve been with DH since May, and I ran WeatherIcon 2.0 from then to now, and suddenly, without me doing it, it doesn’t work, I only upgraded WP the other day.

So something for my site changed suddenly. At least my sidebar has wittled down in height and width. ?? (the error is gone since I ditched the plugin, and the space the plugin data took up is now vacant. I liked the plugin, but am not super-needy for it, thankfully!)

Are you sure you reset the cache folder permissions to 777? The only time I get fopen errors is when I’ve done something (such as installing or upgrading) and the cache folder isn’t writeable….

I started getting this error many hours after I upgraded WP, and, matter of fact, I did not overwrite the wp-content folder at all, I left it totally alone during the entire upgrade process.

This error happened late and so I went and did just as you are writing about, chmod it to 777, I also went and read stuff and so I tried setting permissions back to 755, as it had been running all along that way previously. I never had done a 777 chmod and something I’ve read at DH states that 755 is what I need anyhow.

The point here is, I have chmod’d 777 and 755 both, and neither caused the plugin to work correctly since it started throwing the error. It’s a sudden difference, and I have read about the allow_open thing other places, and looking into the inner workings of weathericon.php it does have two “fopen” statements, and that’s what the error I was getting was about, I didn’t copy it, and can’t recall the exact language of the error, but it’s the same one that I’ve seen other places regarding allow_open being disallowed on the server and “fopen” no longer working.

It is something that I don’t care to delve deeper into. I ran this plugin just fine before, and now suddenly can’t, despite multiple attempts to “fix” it. It’s not anything important, so I just am moving on, and wanted to write out my saga to add to the thread. It might be that someone else can help, or it might help someone else.

It’s simple probably to re-write that part of the code to do something else, but I have my mind occupied with bigger fish which I need to fry, and am not really a coder, just an HTML CSS coder with a bit of PHP savy understanding, not much though. ??

Well I can assure you that it does cache, for me at least. When running it on my local dev blog, I can tell when it’s past the cache time as it takes a bit longer to load the page while it fetches the METAR data via my slow connection.

But that shouldn’t matter too soon as I think we’re switching to caching into the database.

As for fopen, error messages, etc., I’ll point Garett to this thread as he’s more familiar with that part of the script than I am. Perhaps we’ll look into adding a backup retrival system or something though (like using include() or something).

include would still use allow_url_fopen. Your best bet is using the snoopy class, which is included with WP

Yeah, that’s Garett’s department. I get lost in that part of the script, lol.

As for the fopens, only one is a remote one I believe. The other is for opening the cache.

Anyway, I just talked to Garett and he says wait a few days as he’s currently working on a fix that should fix this.

He would like the exact error message though to make sure, so if you could post it… ??

I took the whole thing off my WP install and all I can recall is it referred to “line 681” in the plugin and was definitely mentioning “no such file or directory” in regards to the METAR file …

When I did uninstall it the first time, I took it out, then reloaded the whole thing as a brand new plugin install. There was definitely NO file put into the cache folder. I didn’t take it all out right away, reloaded my site index page many times over the next several minutes. The actual part on that page I had two local stations called up, as well as Lufkin, TX. All three showed data that was different from each other, as in working right, maybe, I didn’t compare it to any other weather site info, but each function call had that same error on it, and I rechecked and rechecked over and over for anything in the cache file. Nothing ever showed up.

Like I said before, I had done chmod 777 after this problem started, but that shouldn’t be a problem, it worked flawlessly the day before and all the days before that. It must be somehow that DH changed something on me suddenly. So it’s the fopen allow_url thing that’s the problem, I’m sure of it as far as I can be with what I tested out FWIW.

I’m not going to “try again” right now, maybe later. I’m in the middle of other things currently. A fix being done first to the files is what I’d desire anyhow, so I’ll wait until there is one out. Thanks!