Can't Delete Comments from the front end of bbpress (support or ideas)

[Ipstenu]

I've noticed this on both the support forums AND ideas.

When I delete a comment, it doesn't delete unless I go into bbPress' backend and delete there. It gives the false feeling that it's deleting by ajaxing away the post, but if I refresh the page, it's still there. I thought it had to do with the weird latency issues we've been facing, but the bbAdmin side says the post isn't deleted.

SPAMMING works fine weirdly enough.

I've tried deleting all cookies and re-adding them. Issue happens on Chrome and Chromium.

[Otto42]

Does it happen every time, or only sometimes?

I just tested, and I'm able to delete things with no issues right now.

[Otto42]

Also, when it does happen, wait for a bit and see if the post eventually "deletes itself" without further action from you.

If this is the case, then the problem is replication lag. We run on multiple database servers, one of them gets data written to it, the others are all read-only. The read-only ones are used for, well, read operations. The master one gets all the writes. So if there is any sort of delay in the sync across to the other servers (and there often is), then that would explain the behavior. It would also explain it being intermittent, because the servers are not always under heavy load.

But the replication will happen eventually. It's just not guaranteed to be instant.

[Ipstenu]

Happens every time. Always. If I go into the bbAdmin section to see if the post is deleted, it's not. Came back WEEKS later on ideas, it still the post wasn't deleted.

I've not had it work properly for over a month.

[Otto42]

Well, that's quite odd then.

It is definitely working fine for me right now. Tried it on four different threads. Deleting, undeleting, and spamming/unspamming all worked.

[Otto42]

Question: Are you using https-only? Try using the HTTPS Everywhere extension in your browser. Cookies may need to be cleared if you were not using https previously.

[Ipstenu]

I'm using HTTPS everywhere, on a new browser as it happens :) I have nuked all cookies for wordpress.org multiple times.

Example: ​http://wordpress.org/support/topic/please-ignore

Deleted the second "I told you so" post :)

Hit refresh and it's back. Went into ​https://wordpress.org/support/bb-admin/posts.php?forum_id=0&post_author=ipstenu and the post is still there, clearly not deleted.

[Otto42]

I don't doubt you, but I cannot reproduce your results. It doesn't happen for me. It deletes and undeletes for me just fine.

[dd32]

I can duplicate it by viewing the support forums over HTTP, although can't with SSL.

XMLHttpRequest cannot load https://wordpress.org/support/bb-admin/admin-ajax.php.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://wordpress.org' is therefore not allowed access.

[Otto42]

The failure over non-SSL is expected. We're planning on going 100% HTTPS at some future point. Maybe as soonish as next week.

Anyway, the various admin bits require HTTPS at present, which is why I asked about SSL earlier. If she is using HTTPS, then it should work. The fact that she posted an http link to the support topic tells me that this is probably the issue. HTTPS Everywhere should prevent that though.

Ipstenu: What about if you visit the forum using ​https://wordpress.org/support/topic/please-ignore instead? Note the "s".

[Ipstenu]

Here's what's stupid. I AM using HTTPS everywhere. It just apparently sometimes ignores WordPress. I even have it as a force 'experimental' rule for WordPress (and Google), and all my bookmarks are https. If I absolutely force it on, it's working, but if the internal links have http, then sometimes even with https everywhere, it doesn't default to it like it should.

I think it's because I didn't set Quantcast as ALSO experimental HTTPS. That's the only thing that was unchecked.

[Otto42]

Hey, if you find links that are not https and which are not also in user-submitted content (like forum posts), then that is indeed a bug.

We've been trying to find any non-relative links anywhere and adjust them. Now, I haven't gone and added any filters or anything for actual content, but for anything else in the page generation itself, links should all be protocol-relative, so there shouldn't be any case where you have an http link from an https page.

As for quantcast and such, those should all be using relative links too. If you find any that are not, report 'em and we'll fix 'em.

[Otto42]

Closing this for now, since it should be fixed when we absolutely force https in the future.

However, please continue to report any cases of https-breakage from bad non-content links or similar.

[nacin]

XMLHttpRequest cannot load https://wordpress.org/support/bb-admin/admin-ajax.php.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://wordpress.org' is therefore not allowed access.

For the record: WordPress would handle this cross-SSL fine, as it issues appropriate headers for admin-ajax requests. It's just older bbPress that doesn't support this.