branch

Ha! I think I got it. The foreach I needed is:

foreach ($query1->posts as $key=>$value){
	if (!in_array($value,$query2->posts)){
		unset($query1->posts[$key]);
	}
}

Object syntax for the win.

I still need to figure out where the bizarre entries with nothing but a single “word” in them are coming from. I suspect this is another case like the “empty” category descriptions that actually contain a break tag. But the comparison is working, at least.

If you’re using 2.7 native threading of comments, Thread Email Reply should work.

@design_dolphin
I salute you for being willing to help out fellow WP users who can’t read little, tiny font.

But usability should not be something that WP needs to be hacked to produce.

It can’t be done natively anywhere but wordpress.com. Considering the bugs in implementation, over there, this could be just as well. If you don’t want to muck around with Gravatars, you could use a plugin like Local User Avatar.

Update: Apparently there was something in my .htaccess files that I could not edit with the interface I was using. I think the lesson here is to copy .htaccess files so as not to actually lose anything and then just delete the suckers. If it works, then rules can be added back in one at a time to make sure they’re not causing any problems.

I do not use the default theme, but I’m not sure how this is pertinent. The issue is that “comment_parent”, in the comments table, is somehow being set to “0”. I checked that, because it seemed so peculiar and everything else is threading properly.

I am approving these by clicking on the link in the notification email that says ‘approve this’, which takes me to my admin interface comments area, and clicking on the button for ‘yes I really want to approve this’.

Unfortunately, the commenter in question has not reappeared, and I have not had any other comments held for approval which makes it hard to duplicate the problem.

I have had this problem, too, with the fourth installation I upgraded (all on the same server, which makes it especially vexing), and am also waiting on very slow help from my host. Does anyone have any ideas how to fix it?

Aside from deactivating plugins (tried) or flushing my .htaccess files (tried) or erasing and re-installing files (tried) or checking the blog url in my options table (just as it should be) or using default urls (already do).

Yeah, this doesn’t seem to be documented yet, like a lot of other things. There’s a new function in 2.7 that generates log-out links and inserts the ‘nonce’ now required. So, down where your log-out link url is, replace the whole thing with this:

echo wp_logout_url();

If you want to do a redirect back to the page you were on, use this:

<?php echo wp_logout_url(); ?><?php echo '&redirect_to='.$_SERVER['REQUEST_URI']; ?>

It took me a while to find this one, too!

This is still a problem, but it has gotten a little less so with RC1. Updating/posting/etc. now seems to take about 15-20 seconds.

Whatever is being done… um… do more of it?

@familiar: Yes, I’ve tried this in Camino (Gecko kernal browser for Mac) and Safari, and both of them have the delay.

*frowns* Now I think about it, you know, I don’t think this was happening when I was using the 2.7 pre-beta nightly builds. I remember doing a lot of comment-threading testing with the later versions, again in both browsers, and I don’t remember this huge delay.

@familiar

Okay, I tried that on a Settings page. The changes did not show up in the second window until the first window (in which I had clicked save) finished processing/loading. I reloaded four times, over the course of the first window’s delay, and none of those page loads (which were of reasonable speed) showed the new setting until the first window was done.

I have no idea how diagnostic this is, but my browser’s “what I’m doing” message, for the first window, was “waiting for domainname.org…”.

It isn’t the loading slowness I’m worried about. I saw the ticket for that, but my page loading slowness, while it doesn’t thrill me, isn’t the problem I’m talking about.

It’s writing information of any kind, and it’s taking at least half a minute every time, for every such action. I’m not exaggerating this, I clocked it to make sure; and thirty seconds of staring at my “things processing” cursor spin after I hit ‘save settings’ or ‘post’ or ‘upload’ is a really, really long time.

No, it’s not additional ping services. I never use anything but the pingomatic that comes already set. I’d think it would be very strange if that affected the time it takes to save a new setting, in any case. It’s everything that’s slow, not just posting–saving, uploading, everything.

I have only tried this with WordPress Thread Comments, since that’s what I have run, but 2.7 picked up seamlessly from that one. If BTC uses similar database entries, then I presume it will work with that, too.

Actually, I remember I started out with BTC, and switched to WTC, and I think those two were interoperable, which is another hopeful indication.

Happily, this appears to have been a beta glitch, and it doesn’t happen in beta2.