traffas

I sent an email, but just used the “roll back to 1.7.4” option in the plugins menu and everything is working again! I’m not sure if that option was there earlier or if it’s something you just added, but thanks!

Still having the same issue – all Otter blocks except Masonry are missing. Existing blocks are broken on page update. It’s not browser-related and I’ve cleared all server caches and WordPress caches. Is there a way to revert to a previous version until a fix is released?

Hitting the same issue — Otter blocks are gone except for Masonry and updating any page using an existing Otter block breaks it. Can someone provide more information about which caches to clear? I’ve tried it in a fresh browser that has no history with the site in question and it doesn’t fix it. Private browsing also doesn’t fix it. It doesn’t seem related to the browser, at least for me. What can we do? I think this is definitely not resolved.

I’ve successfully been able to fix this bug by changing line 29 of output/gigpress_related.php to be

$date_condition = "IS NOT NULL";

I have to fix it with each release, but it beats getting this error all the time.

You’re quite right – I’m so sorry…I saw 5.6 which was the PHP version and not the WordPress version. I’ll be removing my review.

I think I figured it out. The wp_notify_moderator checks to see if the post author (why?!?) can “edit_comment” – a capability that is listed as added in WordPress 3.1 but not explained in the Codex – https://codex.www.ads-software.com/Roles_and_Capabilities#edit_comment

I ended up having to redefine wp_notify_moderator to disable author comment notifications.

Hopefully this explanation helps someone else.

So after further digging, it seems I was wrong about my expectations. It seems ( around line 1400 in wp_includes/comment.php) that wp_notify_postauthor is only triggered when the comment is a approved.

So why, then, is the post author being notified by wp_notify_moderator? Shouldn’t this function only notify the moderator and not the author?

Any resolution to this problem? I’m seeing the same thing.

Any luck with this? I’m experiencing the same problems.

I would sure like to know the answer to this question as well. I’m not interested in debugging WordPress, only my own plugins.

I’ve actually solved this problem (CF7 v. 3.3.2 and WP 3.5 and earlier) by changing a couple of lines in the modules/special-mail-tags.php file.

Change line 8 to
function wpcf7_special_mail_tag( $output, $name, $html=false ) {

And change line 82 to
function wpcf7_special_mail_tag_for_raw_post( $output, $name, $html=false ) {

Whatever is calling these functions isn’t passing the html variable, so providing a default solves the problem of some forms sending but not displaying a success message.

Was there ever a resolution to know for sure if a page is not being cached? Is it the inclusion of the “request URI is rejected” language that says it’s not cached? If that’s not there, can we assume it’s being cached?

Is there a better documentation somewhere for the DONOTCACHEPAGE options than that which is included in the FAQ?

I’m having serious Opera problems as well since upgrading. These problems happen on multiple sites on multiple web hosts on multiple themes and plugin configurations. What can we do to help fix this problem?

“Switch to a different browser” isn’t a fix. I’m having the same problems since upgrading to 3.2.1 with Opera and am forced to (slowly) use Firefox. What is the process for filing whatever bug reports are required to get this fixed?