Browser: All
OS: All
URL: NA
Since deploying V2, sites using PublishPress Capabilities crash for users who have custom capabilities. These users have no access to Bricks, but I suspect the new granular system in Bricks is causing the PublishPress plugin to break. Sadly, disabling one or the other is not an option, but doing so resolves the issue. I have opened a ticket with PublishPress as well, but everything was working until Bricks was updated.
I just heard back from the Publish Press team.
The cap property of a post type object is supposed to have nothing but string-valued properties. It sounds like Bricks Builder 2.0 has added another property with an array value. If so, that is going to cause a lot of compatibility issues, so you should contact their support and ask them to ensure the $post_type_obj->cap object is not corrupted with invalid property values.
The error is
PHP message: Warning: Array to string conversion in /var/www/wp-content/plugins/capabilities-pro/includes/cap-helper.php on line 65 (https://mysite/integrated-service-networks/wp-admin/) [wp-content/plugins/capabilities-pro/includes/cap-helper.php:65 array_unique(), wp-content/plugins/capabilities-pro/includes/cap-helper.php:24 CME_Cap_Helper->force_distinct_post_caps(), wp-content/plugins/capabilities-pro/includes/cap-helper.php:20 CME_Cap_Helper->refresh(), wp-content/plugins/capabilities-pro/includes/functions.php:59 CME_Cap_Helper->__construct(), wp-includes/class-wp-hook.php:324 _cme_cap_helper(), wp-includes/class-wp-hook.php:348 WP_Hook->apply_filters(), wp-includes/plugin.php:517 WP_Hook->do_action(), wp-settings.php:727 do_action(‘init’), wp-config.php:53 require_once(‘wp-settings.php’), wp-load.php:50 require_once(‘wp-config.php’), wp-admin/admin.php:35 require_once(‘wp-load.php’), wp-admin/index.php:10 require_once(‘wp-admin/admin.php’)]
Same here. Publish Press Capabilites ist recommended by WSForm so that editors can see the tables for contact forms, etc too. For this reason I have installed it on several projects. They all crashed with fatal errors when updating to bricks 2.0. The problem is indeed the array data type. Capabilities should be strings not arrays as it is stated in the wordpress developer guides. I hope they can fix this soon somehow…
Exatly have the same error on my projects using publishpress capabilities when update to V2
Hi @stphnwlkr ,
Thanks for reporting this.
This should be the plugin, am I right?
Could you please let us know how to easily reproduce or trigger the error?
Regards,
Jenn
Just to report the same issue w/ PublishPress
Reproducible by having both Bricks 2.0 and PB installed. (as far as I can tell, this is the common denominator as the error msg are the same as OP) — the PB settings might differ on sites, but def a conflict between the two when PB has custom capabilities added - it seems.
edit: and as @mmai stated - most likely due to the WS Form capability (could be other custom cap as well, but this is def one that is common for both of us)
Need a fix for this please! This conflict with Capabilities Pro is breaking our site!
Thanks guys,
We are investigating this issue.
Regards,
Jenn
You can downgrade the version of brick while the team fix this issue, i return in my sites to v1.12 and worsk fine again
Hi @itchycode . Thank you for your respone. Here are my steps:
Ein Fehler vom Typ E_ERROR wurde in der Zeile 66 der Datei /var/www/vhosts/…/httpdocs/wp-content/plugins/capability-manager-enhanced/includes/cap-helper.php verursacht. Fehlermeldung: Uncaught TypeError: Cannot access offset of type array in isset or empty in /var/www/vhosts/…/httpdocs/wp-content/plugins/capability-manager-enhanced/includes/cap-helper.php:66 Stack trace:...I modified the cap-helper function to see whats going on:
// count the number of post types that use each capability
foreach( $wp_post_types as $post_type => $type_obj ) {
foreach( array_unique( (array) $type_obj->cap ) as $cap_name ) {
if(!is_string($cap_name)) {
dump($type_obj);
}
if ( ! isset( $this->all_type_caps[$cap_name] ) ) {
$this->all_type_caps[$cap_name] = 1;
} else {
$this->all_type_caps[$cap_name] = (int) $this->all_type_caps[$cap_name];
$this->all_type_caps[$cap_name]++;
}
}
}
The type object causing the error was this:
WP_Post_Type {#3134 ▼
+name: "bricks_fonts"
+label: "Benutzerdefinierte Schriftarten"
+labels: {#3138 ▶}
+description: ""
+public: false
+hierarchical: false
+exclude_from_search: true
+publicly_queryable: false
+embeddable: false
+show_ui: true
+show_in_menu: false
+show_in_nav_menus: false
+show_in_admin_bar: false
+menu_position: null
+menu_icon: null
+capability_type: "post"
+map_meta_cap: false
+register_meta_box_cb: null
+taxonomies: []
+has_archive: false
+query_var: "bricks_fonts"
+can_export: true
+delete_with_user: null
+template: []
+template_lock: false
+_builtin: false
+_edit_link: "post.php?post=%d"
+cap: {#3135 ▼
+"edit_post": array:1 [▼
0 => "bricks_full_access"
]
+"read_post": array:1 [▼
0 => "bricks_full_access"
]
+"delete_post": array:1 [▼
0 => "bricks_full_access"
]
+"edit_posts": "edit_posts"
+"edit_others_posts": "edit_others_posts"
+"delete_posts": "delete_posts"
+"publish_posts": "publish_posts"
+"read_private_posts": "read_private_posts"
+"create_posts": array:1 [▶]
}
+rewrite: false
+show_in_rest: false
+rest_base: false
+rest_namespace: false
+rest_controller_class: false
+rest_controller: null
+revisions_rest_controller_class: false
+revisions_rest_controller: null
+autosave_rest_controller_class: false
+autosave_rest_controller: null
+late_route_registration: false
}
As you can see, some cap properties are now arrays and are causing the error. Hope this helps. I know it should be checked but on the other hand it is stated in the documentation that they should be strings and not arrays. I fear there will be other plugins out there which will cause bugs with this new structure. Since I do not need the bricks capabilities you could provide us with a php filter or action to just turn it off.
Hi everyone,
Thanks for the reports and investigation.
We couldn’t find it explicitly stated in the WP docs that capabilities must be strings and not arrays, but it’s clearly implied. Every example uses strings, and that’s the convention other plugins rely on. We’ve added this to our to-do list and will work on an improvement/fix to avoid these conflicts.
Apologies for the delay. When Bricks 2.0 is installed with PublishPress Capabilities and custom role settings are present, it throws a fatal error every time. The only option is to disable Capabilities, which in our case, is not possible. Users without a custom role or custom settings are unaffected.
Do you expect this to be a “next release/update” fix, or do we need to downgrade (not ideal)?
Any timeline for this? I have sites that cannot be managed by the client. Weighing the options of rolling back or waiting.
We don’t normally provide ETAs for bug fixes, but we’ll try to include this in our upcoming release.
Sounds like a tough conflict between Bricks V2 and PublishPress. Hopefully, the plugin developers can sort out compatibility soon.
Initial testing indicates that 2.0.1 appears to have resolved the issue.
Yep, we’ve fixed this issue in Bricks 2.0.1, now available as a one-click update in your WordPress Dashboard.
Please take your time to read the changelog entry before updating: Bricks 2.0.1 Changelog – Bricks, and let us know if you continue to experience issues.