Browser: Chrome 110
OS: macOS / Windows / Linux / etc.
URL: Pridať podujatie | Kam v RS
Video: https://youtu.be/fsbFRFoY5aw
This report was drafted with the help of AI (Claude), based on my own requirements, test results, and the Bricks 2.4.2 source code, and I have reviewed its content before posting.**
Summary**
Since Bricks 2.4, a Form with the “Create post” action fails for logged-out visitors as soon as a taxonomy is mapped and a term is selected, even though “Disable capability checks” is enabled. The post is not created.
Error shown in the form
“You do not have the required capability to assign terms in .”
(Localized on my site: “Na priradenie výrazov v taxonómii Kategórie podujatí nemáte požadované oprávnenie.”)
Environment
- Bricks 2.4.2 (child theme active)
- WordPress 7.1.3, PHP 8.5.10, MariaDB 11.4.12
- Other active plugins: ACF 6.8.10, Code Snippets 3.10.2, Rank Math SEO, Redirection, WP Mail SMTP, UpdraftPlus, ManageWP Worker, 2 small custom plugins
- Custom post type with two custom taxonomies
- Cloudflare Turnstile enabled on the form
Steps to reproduce
- Create a Form element with a text field (post title), a select field whose options are existing term IDs, and any other fields.
- Actions: “Create post”. Post type: the custom post type. Post status: Pending.
- Enable “Disable capability checks” (createPostDisableCapabilityCheck).
- Under “Taxonomies”, map the select field to a custom taxonomy.
- Open the page logged out and submit the form with any term selected.
Expected
Same behavior as the post type check: with “Disable capability checks” enabled, the submission is accepted and the existing term is assigned. The docs state that with this option enabled, non-logged-in visitors can create content through the form.
Actual
The submission is rejected with the error above. It happens with every term of the taxonomy. With the select left empty, the form submits fine.
Cause (from reading the 2.4.2 source)
- includes/integrations/form/actions/create-post.php, line ~20: the post type capability check is wrapped in
if ( empty( $form_settings['createPostDisableCapabilityCheck'] ) ). - Same file, line ~109:
validate_taxonomy_mappings( $form, $form_settings['createPostTaxonomies'] ?? [] )is called without considering that flag. - includes/integrations/form/actions/traits/custom-field-handler.php,
validate_taxonomy_terms()(@since 2.4), line ~368:
if ( ! empty( $taxonomy_object->cap->assign_terms ) && ! current_user_can( $taxonomy_object->cap->assign_terms ) )
returns the WP_Errorbricks_assign_taxonomy_term_forbidden. - The
edit_termscheck further down (for terms that do not exist yet) is also unconditional.
Suggested fix
Skip the assign_terms check when createPostDisableCapabilityCheck is enabled. Ideally keep the edit_terms check for non-existing terms, so visitors still cannot create new terms through the form. Alternatively, add a filter that lets developers bypass the check for a specific form.
Workaround (currently applied on my site)
I removed the taxonomy mappings from the Create post action and added the category and location options to the select fields manually (plain text values). The taxonomy terms are now assigned by hand when the pending post is reviewed.
Live example
This form currently runs with the workaround above, so it does NOT show the error anymore. The bug appears as soon as a taxonomy is mapped again under Create post → Taxonomies (with “Disable capability checks” enabled) and a term is selected.
I can set up a separate test copy of the form with the mapping enabled, if that helps you reproduce it.
Regression
The same form, with the same settings and taxonomy mapping, worked on Bricks 2.3.x (logged-out submissions assigned the selected terms without errors). It broke after updating to 2.4.x.