Meta Box

the filter function is returning the $show_delete var. it was missing in the above example:

function fix_frontend_delete_button ( $show_delete, $post_id ){
	$post_type = get_post_type( $post_id ); //workplace
	if ( !current_user_can( 'delete_'.$post_type.'s' ) ) {
		$show_delete = false;
	}
	return $show_delete;
}

I would be delighted to explain, Tran!

The short version is because developers build things beyond the default WordPress setup and want to use this great set of meta box plugins to do so.

We are using WordPress along Meta Box and MB User Profiles to create rapid prototypes that include a large, and very complex set of Forms in the user profile area.So many fields, in fact, they needed to be grouped into Tabs. So Complex, in fact, we quickly outgrew using the MB Tabs extension and started using a very clever plugin called WP-User-Profiles to separate the field groups into Tabs. These tabs and sub-tabs have their own screen id's such as: "admin_page_services" for when the user is viewing a tab called "services" under their own profile and "users_page_services" when an admin is viewing a users's service tab. So far so good? good.

Now, it's not a problem to have the meta-boxes appear in these new tabs in the user profile. we simply assign the post_types attribute when we create the metabox like so:

'type' => 'user',
'post_types' => ['admin_page_service','users_page_service','toplevel_page_service'],

The problem, and the reason we have modified the mb-user-profiles plugin--well, actually the mb-user-meta plugin that is included in this plugin--as described above for the last four years is that all scripts that make metabox so nice for users profiles such as the validation, special advanced fields and so on are hard-coded to only be loaded on "user profiles" that have screen ids of:
array( 'profile', 'user-edit', 'profile-network', 'user-edit-network' )

Feel free to reach out to me on Github or directly via email if you would like to have a closer look at how we are using your plugins. It's probably one of the more advanced use cases given the number of times pull requests have been submitted when we run into a limitation.

Yes. this is a valid solution.
This issue can be marked as resolved.
Thank you.

The CSS workaround would work if I could assign a class to the submit button. Is this possible? An ID can be assigned using the id_submit but then either:
a) custom CSS to hide multiple submit buttons by their unique ID if they exist on the same page would need to be created. or
b) a new id_class attribute would need to be added to the plugin allowing one CSS class definition to be used to hide the submit button.

of course, something like id_submit="hidden_submit" could be used in conjunction with a single CSS ID definition, but then, when multiple forms are used on the same page (or in different tabs on the same page), multiple elements with the same ID would exist in the DOM. Not good.

As many times before, I will modify the plugin to get around this issue for the immediate need and would be happy to submit a pull request.

Found the issue:
fields/post.php line 181:
public static function search_by_title( $search, &$wp_query ) {
should be:
public static function search_by_title( $search, $wp_query ) {
remove the & symbol before the variable.
Shall I submit a pull request?