Hi zwene,
you may try <input type="hidden" name="post_view_cap" value="CAPABILITY" /> where the value of CAPABILITY is read for logged in users, exist for everybody, any WP rolename or Access Area capability (the userlabel_N_* things found in the right column under Users / Access Areas).
I can’t really say if this will work with the EO Frontend Submissions (I did not buy it yet, and I don’t plan to do so.). Likely it won’t, because the plugin might only use those $_POST values it knows about.
Thread Starter
zwene
(@zwene)
Hi podpirate,
thank you for response. 🙂
I tested a lot of combination but it don’t work. 🙁
Where are you storing the *_view_cap values for a post? Wouldn’t it be easier to interact with other plugins and scripts to store them (alternatively) as a meta key? Or look if a meta key
_post_view_cap
_post_edit_cap
_post_comment_cap
like
_wpaa_fallback_page
_wpaa_post_behavior
exists and use the values of this meta keys instead then? This would be a great help. 🙂
And btw.: On the option page I edit the standard value for the event post type. Have you an idea why the standard values aren’t used if you create a new object not in the backend?
Greetings,
zwene
I think I got it. Being a bit savy on memory the plugin is not loading the admin classes in the frontend. I will think of a way to do this in a more generic way (like every time a post is saved).
For now this one might help. Tested together with WP User Frontend, which might be a similar scenario to your use case:
function wpaa_insert_post_data_filter() {
// (a) in admin the filter is already set. (b) will be true if plugin is active:
if ( ! is_admin() && class_exists(‘UndisclosedEditPost’))
add_filter(‘wp_insert_post_data’, array( ‘UndisclosedEditPost’ , ‘edit_post’) , 10 , 2 );
}
add_action(‘init’,’wpaa_insert_post_data_filter’);
The filter function UndisclosedEditPost::edit_post() will either set the default access from the settings on a new post or – if the user has permission – populate it from $_POST['post_*_cap']. (“Permission” here means: being capable of the value in $_POST['post_*_cap'] AND being allowed to edit the *_cap.)
FYI: The plugin is creating three additional columns in the posts table post_view_cap, post_edit_cap and post_comment_cap. This is mainly to avoid additional JOIN statements when retrieving large amounts of posts like on an archive page, but also for being safe from undefined or empty or invalid or multiple post_meta values.
all the best,
podpirate
Thread Starter
zwene
(@zwene)
Hi podpirate,
thank you so much, the filter function works perfectly. 🙂
>Tested together with WP User Frontend,
>which might be a similar
>scenario to your use case:
This plugin looks interesting. I will have a look on it. Thank you for the tipp. 🙂
Greetings,
zwene
