Conversation
supportHi, for new posts created in the backend I can choose the standard read/write access group. That works well. If I create a new post/event eg. with Event Organiser Frontend Submission Form the option I made isn’t used. Instead read/write is “WordPress Standard” at this posts/events again. Is there a way to give a frontend made post/page the read/write option on there way? Eg. with a hidden field like <input type="hidden" name="access" value="logged-in"> ? Greetings, zwene https://wordpress.org/plugins/wp-access-areas/
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.
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
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
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.
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
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