Recent Posts Widget with Category Exclude hack failing

Seeing that this is an intermittent issue, I really doubt there’s a issue with the code you posted. In any case it looks fine to me as well. Code tends to work or not work, very rarely is it a sometimes works issue.

It could be due the DB being slightly corrupted, a problem with caching, or possibly even a physical server problem. It could also be some other code is changing data where it’s not supposed to. Tracking down any of these will be very difficult unless you can determine a way to cause the error to occur on demand. There’s some options table maintenance operations you might be able to do through phpMyAdmin, depending on privileges granted by your host. Always make a DB backup before doing any table maintenance. It’d be a long shot for it doing any good.

A rather weak solution would be to define a default value for when this happens. You can insert the default IDs between the single quotes after the question mark (just like you would on the widget form) of this line in the widget() function:
$exclude = empty( $instance['exclude'] ) ? '' : $instance['exclude'];

Whatever is entered on the form will take precedence over this, it’s just a backup for when the proper data disappears.

@bcworkz thanks so much for looking at this – I hope you won’t mind another question!

Since my initial post I’ve been doing a lot of reading on constructing widgets….there is still a lot for me to learn for it to really gel in my head, but one thing I notice in this particular widget code is that there are references to two different(?) widget names….

In some places it’s referred to as “widget_recent_entries” and in other places as “widget_recent_posts” ….. is that normal? Would you mind explaining the two name references?

I really do like your solution of using a default ID if one is not entered (or entered but disappears), but the downside is that I cannot then use the widget on the one category page where I want that ID used to show ONLY posts from that category (by excluding all the other category IDs), so what I may wind up doing is duplicating the widget with one version using the category ID I want excluded as the default, and the duplicate version excluding all other category IDs except the one I want to display.

Thanks again!

@trisham, I just got an email since you @lawless’d me.

I just dropped that code in a current site I’m working on and it seemed to work as expected. I’ve got error reporting turned on, and the only thing I saw was a warning about an unset variable which wouldn’t cause your issue.

In digging deeper it seems since WordPress 2.5 the wp_cache function this code uses, does not store wp_cache data persistently, which my be why you are seeing intermittent issues. The Exclude Category value gets stored in wp_cache, then once the cache is destroyed, your Category value gets removed.

My guess is it’s somehow related to that. I just dug into it a little bit and didn’t see anything obvious, but it’s been 4 years since I’ve even looked at that code. I’ll try and play with it a little more this week in my spare time.

@lawless – thanks so much for taking a look! And huge thanks for creating this to begin with, it’s a great bit of code and I’ve learned a lot about widgets just from reading and using it.

I thought perhaps the cache might be an issue, I was just reading about that….but it is certainly a nice widget and I could see many other folks wanting this functionality, it’s a shame it isn’t built into the stock WP Recent Posts Widget, but maybe someday… ??

Little more info. The title, number, and exclude data are being store in the database in the *yourprefix*_options table. Do you have access to your database via phpMyAdmin or something similar?

There is a field in the ‘option_name’ column called ‘widget_recent-posts’, that stores the values in an array that looks similar to this:

a:2:{i:2;a:3:{s:5:”title”;s:0:””;s:6:”number”;i:5;s:7:”exclude”;s:1:”1″;}s:12:”_multiwidget”;i:1;}

So caching shouldn’t affect that. It’s persisted in the database.

Widgets are weird little creatures and I’ve never fully understood them. I’ve run into similar issues in the past, usually when migrating sites where I’d lose all Widget data.

The weird thing in your case is the intermittent behavior. Like bcworkz said, it should just work or not work.

Can you give us any more context as to when it ‘forgets’ the exclude category?

Making new posts, when a comment gets added, etc. That may help identify some action that is triggering a behavior that is causing the problem.

Hi Trisha,

The recent_entries vs. recent_posts bit was inherited from the original widget code that yours is replacing. I can’t speculate why there are different terms, but they don’t do any harm except to confuse us. They serve different purposes. As long as the correct term is consistently used for the right purpose, it’s all good.

I agree with you and lawless that the caching has something to do with it, but I’m not sure where the logic flaw lies. My inclination would be to not worry about the cache and always work with the DB and not the cache. The cache should be able to work out the changes, though what users see may be stale data for a while. At least the DB will have the correct values.

Usually the reason for directly dealing with the cache is to be more efficient in the case of heavily trafficked sites. But if lawless can workout the logic flaw then working with the cache would be fine.

Having a separate include and exclude widget is a viable approach, just be sure the names are different ?? It’s also possible to roll the two logics into a single widget by enhancing the backend form. For example, add a radio select field with include and exclude options to combine with the IDs in the current exclude field. Which radio option is picked determines if the query argument in widget() is “category__in” or “category__not_in”. Everything else can be the same, though “exclude” may not be the best field name any more.