erikdebye

After testing against the previous working version (v3.28.21), the permission gate in permissions.php, the conditions_logic() method (hooked to frontend_admin/show_form), returned immediately once a user passed a form’s permission check. In v3.29.5 (and likely earlier) that early return $settings; was removed, so the code keeps running after a user is already approved and that causes three problems:

1) After the permission rule grants access, the frontend_admin/special_permissions filter runs and actions/post.php runs current_user_can( 'edit_post', $post_id ). That check fails for any role lacking post-editing capabilities, such as Customer, and when it fails the form’s post_id is then set to 'none', unless the special permission “Edit Other’s Posts” is enabled. In our usage, we do not want to grant that permission.
The resulting flow is : a Customer opens the form to edit a post they authored > permissions.php grants access > frontend_admin/special_permissions runs >actions/post.php runs the edit_post check > post_id is removed > the form has nothing to render, so the user sees no form on the front end.

This does not account for the “You do not have the proper permissions to view this form.” message, which ends up being a second issue.

2) With the early return gone, after a matched user is approved, execution falls through to the bottom of the loop where the not_allowed message is echo‘d based only on the rule’s setting and it never checks whether this user passed. So an approved user gets the form and the denial message on the frontend, but the form will still load. I suspect this is why @kyashan22 is seeing the message even as an admin, but I did not have this issue on my site as admin. I did note similar behavior for the Customer role while creating a workaround for this issue.

3) Additionally, conditions_logic() also runs during the submit AJAX request; when it echos that <div>...</div> it writes HTML into the response body before the JSON. The front-end does JSON.parse() on the body, hits the leading HTML, throws, and surfaces a generic “An error occurred. Please try again later.” message even though the payload underneath is success: true. So a submission that fully succeeded reports failure to the user.

I was able to create a workaround for problem #1, with a scoped map_meta_cap filter that grants the Customer role edit/delete rights on Watercraft posts they authored — and only those — so current_user_can( 'edit_post', $post_id ) passes for their own posts and post_id is no longer blanked. It’s limited to the post’s author, so it doesn’t grant any ability to edit others’ posts (which is why “Edit Other’s Posts” wasn’t an option for us).

For problems 2& 3, I updated the forms so “No Permissions Message” is set to “None”. This stops the echo, which removes both the stray message (#2) and the HTML corrupting the submit response (#3).

The workaround:

/**
 * Allow WooCommerce customers to edit/delete only their own Watercraft listings
 * from the front end, without giving them broader post-editing permissions.
 *
 * Frontend Admin checks current_user_can( 'edit_post', $id ). Since customers
 * do not normally have post editing caps, we narrow that check here to the one
 * case we actually want to allow.
 */
add_filter( 'map_meta_cap', function ( $caps, $cap, $user_id, $args ) {

	// Only handle single-post edit/delete checks.
	if ( 'edit_post' !== $cap && 'delete_post' !== $cap ) {
		return $caps;
	}
	// No post ID means there is nothing for us to check.
	$post_id = ! empty( $args[0] ) ? absint( $args[0] ) : 0;
	if ( ! $post_id ) {
		return $caps;
	}
	// Only apply this to Watercraft post type.
	$post = get_post( $post_id );
	if ( ! $post || 'watercraft' !== $post->post_type ) {
		return $caps;
	}
	// Customers can only touch listings they authored.
	if ( (int) $post->post_author !== (int) $user_id ) {
		return $caps;
	}
	// Keep this limited to WooCommerce customer accounts.
	$user = get_userdata( $user_id );
	if ( ! $user || ! in_array( 'customer', (array) $user->roles, true ) ) {
		return $caps;
	}
	// Do not extend this permission to the normal wp-admin post editor.
	if ( is_admin() && ! wp_doing_ajax() ) {
		return $caps;
	}
	// All checks passed. Require only "read", which customers already have.
	return array( 'read' );
}, 10, 4 );

Let me know if you need any other information.

Thanks,
Erik

I unfortunately am still having this issue, now with additional sites. It’s fairly clear that this is more than likely a hosting issue, but per the host’s previous response it isn’t a timing issue. This is almost certainly not a conflict with any particular theme or plugin, as I am now experiencing this issue on multiple sites on the same host with different themes/plugins.

Example Site 1:
Theme: Avada v7.12.1
Plugins: ACF Pro v6.4.2, Avada Builder v3.12.1, Avada Core v5.12.1, Breeze v2.2.11, Gravity Forms v2.9.9, Imagify v2.2.6, Object Cache Pro v1.23.1, Post SMTP v3.2.0, Safe Redirect Manager v2.2.2, WP 2FA v2.8.0, WP All Export Pro v1.9.10, WPS Hide Login v1.9.17.2, Yoast SEO v25.2

Example Site 2:
Theme: Custom ACF-Block Theme
Plugins: ACF Pro v6.4.2, Ajax Load More v7.4.0.1, Ajax Load More: Pro v1.3.1, Akismet v5.4, Beautiful & Responsive Cookie Consent v4.6.1, Better Search Replace v1.4.10, Gravity Forms v2.9.9, Gravity Forms Akismet Add-on v1.0.1, Header Footer Code Manager v1.1.40, Imagify v2.2.6, Jetpack v14.8-a.3, jetpack Protect v4.1.0, ManageWP Worker 4.9.23, Safe Redirect Manager v2.2.2, WP 2FA v2.8.0, WPS Hide Login v1.9.17.2, Yoast Duplicate Post v4.5, Yoast SEO v25.2

A third site is using a custom Genesis theme.

Additionally, I ran some testing with only having the 2025 theme active, with no plugins enabled, and still was not successful in logging in, but I did not reset my QR configuration. Are there any other reasons a hosting configuration could cause an issue? Outside of a timing issue?

I’ve switched to using email on a site and after 24+ hours I can confirm that this method seems to be working.

I’ve only noticed the issue with the app-based OTP after an unspecified amount of time (24+ hours) after set-up or resetting the App OTP.

Note, that since I’ve opened my ticket I also got a new phone on a different OS, but the issue persists.