[Plugin: Better RSS Widget] Cannot save widget settings on an RSS feed

This just in.

The feed DOES appear on my site. I hadn’t noticed because when it failed to save, I figured it wouldn’t.

I guess the workaround is to wait a reasonable amount of time and refresh the widgets admin page.

Now that I see it’s working, more or less, I have a suggestion. This feed looks best if I limit the summary to 0 characters. The plugin puts a summary of ” […]” inside a <div> which appears on a separate line. Ideally there could be a “don’t show summary” checkbox but absent that, if the value was set to zero it would be nice to not generate the <div> at all (or the title=” […]” either).

I may take a gander at the source and do that myself; if I do I’ll send it back to you and you can incorporate it into the next version if you want.

I am not sure why it doesn’t finish the save for you – could be something with the Thesis theme or the feed. I will have a look. If you don’t want a summary to display, simply uncheck that box in the widget.

(facepalm) – didn’t notice the checkbox obviously. Blew right by it.

Unfortunately I don’t have a way to configure my PHP debugger or I’d try to give you more information if you don’t find anything. I’ve been thinking about setting up a staging environment anyway, if I learn anything more I’ll let you know.

Thanks for the quick reply!

Grandslambert, I figured out the source of my problem. I was right at the edge of running out of memory.

It wasn’t long afterwords that I was trying something else and I was seeing PHP fatal errors in class-simplepie.php, so I looked in the logs and there were fatal errors in widget-form.php in your plugin too.

I increased the PHP memory to 64M and it is working like a charm.

Thanks.

The lastest version of the plugin should not have fatal errors in the widget-form.php, but if you are seeing something I would love to see what you are seeing so I can fix those.

It’s failing on line 58 of /better-rss-widget/includes/widget-form.php, trying to allocate 122880 bytes — that attempted alloc pushed me over my 32M limit.

Here’s the line in question:

parent::WP_Widget(false, $this->pluginName, $widget_ops, $control_ops);

It’s in the constructor method for better_rss_widget().

This is just a guess, but is the widget constructor called after options are persisted?

If so, that’s the problem — under low memory conditions (which I was in, but didn’t know it) if this call fails, then it would make sense that you’d see the spinning GIF. As I mentioned, when I refreshed the page the settings had been persisted.

I’m not a PHP expert, so I’m not sure whether out of memory errors can be trapped in a try/catch block (the PHP interpreter would have to reserve memory ahead of time), but that’s the only idea I’d have, to wrap that call in a try/catch block. (It doesn’t look like it’s possible – https://coding.derkeiler.com/Archive/PHP/php.general/2007-10/msg00774.html – but I didn’t look too hard.)

For now, I’m guessing that the best advice for your users, if anyone runs into the spinning GIF problem, tell them to increase PHP memory – if it goes away, that’s the problem.

If WP 3.1 uses more memory than before, it’s not too surprising that people with only 32m might be bumping up against the limit even if they were fine before.

That would most definitely be a WordPress problem because I am extending a WordPress feature to create them widget. If I wrap that in a a try catch block, and it doesn’t work, then the widget will not be initialized. I will talk with other WP Developers to see if I can find a fix for this issue.