Getzel Rubashkin

@chip: Exactly the circumstances I had in mind… in my instance the design did not include a link to comments, making the title the only link to the single post view in the event that there was no ‘more…’ link. Without the title the comments would be unreachable.

Like I said, “Just make sure to call that after the init function that creates the post type.”

You are presumably using add_action to trigger the custom post type. You’ll want to use add_action to trigger the long form taxonomy register AFTER the one that adds the post type.

I just stumbled across posts_where which allows the addition of WHERE clauses to the loop or query. This seems to be the solution to this problem. I don’t need it for anything currently on my to do list, so I haven’t tested it yet, but I am posting it here in case anyone stumbles on this post. It looks like a very useful function.

The long form did the trick for me (see my previous post)

… thinking about it, shouldn’t setup_postdata modify $post->ID? That would be the logical way for it to function…

While you are figuring out what is wrong, the long form will do the job:
register_taxonomy_for_object_type(‘category’, ‘custom-type’);

Just make sure to call that after the init function that creates the post type.

Dealing with the same problem. Assigning custom taxonomies to the custom post type is working, but regular categories and tags are not…

Clarification: revision is stored in post_type, so it would be post_type == revision.

I had an issue with 404 errors resulting from attempts to preview. The site uses WordPress as a CMS, primarily using Pages with only one section using Posts (the message from the president, which is updated on a schedule).

I had set up custom permalinks, which turns out to have been the problem. An easy work-around was to change the permalink structure from /%post-id%/%postname% to /%postname%/%post-id%. It seems to be important to end the link with the ID.

This worked for me since the ID does not show on page urls, which were the ones that mattered, especially since the posts were referenced from within the template, so this did not ruin the ‘prettiness’ of the links at all.

I’m sure this is an unacceptable solution for many, if not most, WP websites, but I thought I’d put it out there.