nateomedia

I have the same problem. 5.4.4.

Okay, figured out how to work around this:

$attachments = $wpdb->get_results("SELECT $wpdb->posts.* FROM $wpdb->posts WHERE $wpdb->posts.post_type='attachment' AND $wpdb->posts.post_parent='" . $post->ID . "' ORDER BY post_date DESC");

This appears to be a bug, but I’m not comfortable filing it because I don’t know why this is happening.

I would also love to see support for HTML 5. Thanks!

You probably got that error because you blog had no content. It also probably means that you’re using an older version of the plugin — it fails more gracefully now.

The plugin lets Mysql do all the post sorting, so it’s server dependent. If your server is localized to Iceland, the sorting should be done correctly. If you’re hosting on a server outside of Iceland, then it might not.

The code is on my website.

The new version of the plugin should do a better job with those sorts of characters. Check out the admin settings where you can now modify the alphabet.

This isn’t true. The plugin always breaks when you don’t have any content in the category that you call. It should probably do so in a more elegant way, but it works just fine.

Yeah, the post contents only display when using WP-SNAP! if you want them to. Just edit your files.

I did some tinkering and WP-SNAP! now supports “pretty” permalinks.

WP-SNAP! v0.8

timothyb — WP-SNAP! will work on the index page or any other page that uses the WordPress Loop.

Gah! Squashed a bug.

WP-SNAP! v0.7.3

I just updated WP-SNAP! to work with WordPress 2.3.

WP-SNAP! v0.7.2

I am very, very happy to announce the release of WP-SNAP! v0.7. The bugs that plagued version 0.6.x should now all be fixed and I’ve even added some new functionality.

The biggest news:

The plugin once again works on Pages!

I’ve made it so that several variables can now be passed to WP-SNAP!, including one that allows you to select the category to be displayed. This is what allows the plugin to now be called on a Page. You can choose to display one category, one category plus all child categories, or all categories.

I’ve also made it possible to select which navigational style should be used when WP-SNAP! is called, making it possible to use the plugin in several different places on your site using a different navigational style in each spot.

Cool, huh? ??

WP-SNAP! v0.7

Thanks for the reply, but this isn’t quite what I need. Your plugin relies on knowing what data to filter before the page loads. I need to be able to decide what data to filter as the page is loading. That is, the most important test will be: has my plugin been called? If it’s been called, alter the data; if it hasn’t been called, don’t alter the data.

add_filter seems to get processed before anything gets called on a template. So, if my plugin is called on the template, nothing that I do within my plugin will effect the add_filter function that I set up. I tried setting up a global variable and was losing my mind trying to understand why it wasn’t working. I echo’d the variable and the modified $where statement that was supposed to be happening through add_filter and could not understand why my variable was showing up on it’s own but not in the function I had set-up through add_filter… until I realized that the add_filter had
happened a long time ago. ??

add_filter cannot, it seems, be called from within a function either. So, I can’t have my plugin get called and then have add_filter run then. That would work fine! But it’s not possible. ??

What needs to happen:

page loads -> plugin called? -> yes -> grab IDs of posts to display, eliminate all others -> run loop

page loads -> plugin called? -> no -> run loop

The solution, I’ve discovered, is to use $wp_query->posts and, in my particular instance, was incredibly easy to implement. I was already using $wpdb to make a database call like this:

$all_posts = $wpdb->get_results("SELECT post_title, post_content, post_excerpt, ID, post_password, post_date_gmt FROM $wpdb->posts, $wpdb->post2cat WHERE post_id = ID AND post_status = 'publish'");

If the plan is for the post loop to be effected by the outcome of that database call anyway, this works just as well (and solved my problem):

$all_posts = $wp_query->posts;

Just pass your results back to $wp_query->posts when you’re done.