goldenapples

Yes… Sorry, I didn’t check these forums for questions recently. Please let me know if there are any specific error messages you get with the plugin.

Thanks for the feedback. I’ll see about working that into the next version!

There are also a couple of actions included in there that you can use. 'right_now_content_table_end' to add rows to the bottom of the left table, and 'right_now_discussion_table_end' for the right side table; plus 'rightnow_end' to add any additional content to the bottom of the table. There aren’t any filters to remove/hide content that I can see, but you could do that with jquery added at any of those action points.

Thanks. I fixed that one. Still, it was functioning as I expected it to… for now, ‘category’ is maintained for backwards compatability.

But the result of the query is still the same when I make that fix. Unless I explicitly disable the pre_get_posts function from QMT_Query on everything but search results, it overrides the taxonomy arguments passed in my get_posts query. No big deal, I’ve worked around it though.

My query looks like this:

$posts = get_posts('category='.$cat.'&location='.$city.'&orderby=date&order=DESC');

where “location” is a custom taxonomy, and one of the taxonomies I have included in the drilldown widget. But without the hack I mentioned above, this query seems to return results from all “locations”, not just the one passed in the arguments.

Just wondering if this was intended behavior, and if so, if there’s a better way of overriding it than what I’ve done. Thanks!

Problem was with another plugin: the Custom Field Template plugin. I think it is fixed in the latest upgrade of that plugin; at least, I’m not experiencing the problem anymore.

Correction: the $file_handler parameter above actually refers to a key in the $_FILES array (i.e. a file upload field from a submitted form), not the object itself.

I just figured this one out – couldn’t find any resources anywhere, but actually (in my case) it was incredibly simple. If users are uploading files that you want to save as attachments, don’t bother going through all the headache of wp_insert_attachment() – there’s a function in the wp-admin section that handles saving uploaded files in the correct directory, attaching them to a post, and generating all the intermediate sizes.

Look at the function media_handle_upload() in wp-admin/includes/media.php. The function that ended up doing the trick for me was this:

function insert_attachment($file_handler,$post_id,$setthumb='false') {

		require_once(ABSPATH . "wp-admin" . '/includes/image.php');
		require_once(ABSPATH . "wp-admin" . '/includes/file.php');
		require_once(ABSPATH . "wp-admin" . '/includes/media.php');

		$attach_id = media_handle_upload( $file_handler, $post_id );

		if ($setthumb) update_post_meta($post_id,'_thumbnail_id',$attach_id);
		return $attach_id;
	}

Hope this helps.

I had the hardest time trying to figure out a similar issue to that. I was able to work around it by using the built in function media_handle_upload(). This wouldn’t work in your case, as it only handles images uploaded in a $_FILES post. But you could take a look at the source of that function to see how it generates the intermediate image sizes.

The function I ended up with, after tearing my hair out trying to make wp_insert_attachment work for me, was just real simply:

function insert_attachment($file_handler,$post_id,$setthumb='false') {

		require_once(ABSPATH . "wp-admin" . '/includes/image.php');
		require_once(ABSPATH . "wp-admin" . '/includes/file.php');
		require_once(ABSPATH . "wp-admin" . '/includes/media.php');

		$attach_id = media_handle_upload( $file_handler, $post_id );

		if ($setthumb) update_post_meta($post_id,'_thumbnail_id',$attach_id);
		return $attach_id;
	}

where $file_handler refers to an object in the $_FILES superglobal.

Hope this helps someone.

Actually, on testing to figure out my problem, I’ve narrowed it down a bit more. The post-type is only being changed if the post title changes, otherwise the correct post-type remains associated with the post. I’m thinking this must be a bug in progress. I’ll report it to the beta-testers list…