Qliphoth

Right, I’ve been looking at that, and the problem is how _update_post_term_count() for taxonomies attached to post types first confirms that the objects are published before counting them.

Ideally, I would like for the default way WordPress works (by hooking into it via functions.php or a plugin) would be for WordPress to just count all posts in a category against it, no matter if the post is in draft, pending, scheduled or published. It feels like that would be less work and require less administration (and fewer possible scenarios that could cause errors) than creating a separate API call to fetch only this “special” count, when I’m already fetching the other category data (id, name, slug, etc) using the normal API call.

It all boils down to this one row in taxonomy.php:

$count += (int) $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(*) FROM $wpdb->term_relationships, $wpdb->posts WHERE $wpdb->posts.ID = $wpdb->term_relationships.object_id AND post_status = 'publish' AND post_type IN ('" . implode("', '", $object_types ) . "') AND term_taxonomy_id = %d", $term ) );

I’m not going to change any of the core WordPress files, I just want the function to ignore that “post_status” part of the query by hooking into it from elsewhere.

Sorry, no can do. The count field correlates with a value stored in the database, so grabbing information about a taxonomy will always only show the amount of posts that are published in that category, no matter what arguments you apply.

The external tool is one of my own making as well, so I’m in 100% control of the code, but no matter how I turn this around, it all comes back to the same thing, I have to change how WordPress returns the “count” of the taxonomy. It has to include all posts in a taxonomy, not just published posts.

Yeah, I know what the shutdown job is, but I’m trying to figure out why it’s taking so long… ??

Alternatively, if there are any XMLRPC hooks you can use for cohosts, that’s even better.

jcow, I’m not sure if you actually read my initial message, where I said quite clearly that “My webhost doesn’t offer too detailed logs about stuff like this, so all I can see is that there’s an error 500, not what’s causing it.”

I’m having the same problem here, too.

[No bumping, thank you.]

Nothing?

Why is this marked as resolved?!

Any ideas? This is throwing a couple of really weird errors my way of late. For example, WP-Polls occasionally believes that people haven’t voted, but if they try to do so, it just tells them that it “Failed To Verify Referer”.

I replaced jquery.js with the un-minified version, and narrowed down the problem to this line:

// Do send the request
// This may raise an exception which is actually
// handled in jQuery.ajax (so no try/catch here)
xhr.send( ( s.hasContent && s.data ) || null );

However, since it refers to jQuery.ajax, I’m not sure exactly how to narrow it down further.

Clarification, when I say “This gives me a blank post.php” above, I mean when I save the post as pending or as draft. It’s as if the addition of information in the URL window causes the submission to choke, but only when submitting as a non-administrator.

Any suggestions here?

Very true! I just checked the console, and I’m getting this:

POST https://www.csicon.org/wp-admin/admin-ajax.php 500 (Internal Server Error) load-scripts.php:4
f.support.ajax.f.ajaxTransport.send load-scripts.php:4
f.extend.ajax load-scripts.php:4
f.each.f.(anonymous function) load-scripts.php:4
(anonymous function) imsanity.js:75
f.extend.speed.d.complete load-scripts.php:4
f.fx.step load-scripts.php:4
h load-scripts.php:4
f.extend.tick load-scripts.php:4

It’s weird, though, I don’t get AJAX-related errors elsewhere, as far as I can see.

Marking this as resolved for now.

Never mind; just disabled Imsanity and it seems my installation is still doing this for some reason.