Skip Navigation

[Resolved] Require approval for user submitted post type (directory listing) after edit

This support ticket is created 5 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

Author
Posts
#1108997

I am building a membership site whereby any member has the ability to create 1 post that appears as part of a directory listing. The directory listings contain a photo, name, contact info, and location information. I have the directory listings created as a custom post type.

After reading some other posts for similar projects, I am having trouble figuring out how to go about doing this.

1) I know I can use CRED to update a post type, but I need any submission or update/edit of the post type (Directory listing) to not take effect immediately. Instead, I would like the user to see what they currently have when they make changes, submit it, and then wait for approval before it is reflected publicly. The current post would stay up as-is (unless they submitted a separate request to disable/delete it). Then an administrator would login, see the submission, and approve or deny it (each with an email notification).

2) How do I tie the post type to a user, so they can create only 1 post, and it is correctly tied to their account (so they are the only person that can edit it, aside from administrators). They will each have a members dashboard screen, so I plan to have a tab there for the directory listing, and it should show either a button to create one, or edit the current one if they have one.

Thank you!

#1109093

1) I know I can use CRED to update a post type, but I need any submission or update/edit of the post type (Directory listing) to not take effect immediately
This isn't how Forms are designed to work, unfortunately, because WordPress doesn't work this way. If you modify a post in wp-admin, it is updated right now. So changes are immediate upon submitting an Edit Post Form, regardless of approval status. The only built-in way around this is to enable the "Revisions" option for this post type (Toolset > Post Types > Edit post type and find the options panel) and set the Edit Post Form to use post status of "Pending Review". This means that while waiting for approval, the edited post is no longer visible on the site. The changes, however, have been applied. The moderator can easily publish the changes or revert to a previous revision of the post if necessary.

A more complex solution involves using an Edit Post Form with generic fields. Instead of editing the actual post title or custom field values, your Users will submit generic fields. Add custom code using the cred_save_data API to set hidden field values with the generic field values. Then use the save_post hook to modify the actual values when the post is moved from pending review to publish. This will require a PHP developer, and depending on the changes you allow your Users to submit it could be quite complex.

#1109098

Thanks for replying Christian.

So I do need the post to stay visible while pending review, as that is a shortcoming of the current website of theirs. Somebody simply adds their phone number and has to wait for a moderator to approve it for their listing to show back up, which is a bit frustrating for their user base.

Thinking about the second option, that might work. Is your thought to have duplicates of all of the custom post type fields as hidden fields, and that is what they are editing? They then submit edits to those hidden fields, and on submit we would need to toggle an unexposed field, a toggle / field named 'pending', to identify the post needs review. Then have a separate view for moderators that shows the current public values, the edits, and on approval replaces the public values with the hidden ones? Decline would just simply wipe these hidden values, reset the toggle, and send a decline email.

In this case, I'd like to be able to have the hidden values hidden in the backend, is it possible to do that? Even if they are visible but can be collapsed and not in view normally.

Second part of my question is how to tie 1 post per user -- any thoughts on how I can achieve that?

Thank you!

New threads created by Christian Cox and linked to this one are listed below:

https://toolset.com/forums/topic/associate-a-post-with-a-user-and-only-allow-user-to-create-that-one-post/

#1109533

Thinking about the second option, that might work. Is your thought to have duplicates of all of the custom post type fields as hidden fields, and that is what they are editing?
Not only custom fields, but any other information that can be edited, like the post title, main content and post taxonomies as well.

They then submit edits to those hidden fields, and on submit we would need to toggle an unexposed field, a toggle / field named 'pending', to identify the post needs review. Then have a separate view for moderators that shows the current public values, the edits, and on approval replaces the public values with the hidden ones? Decline would just simply wipe these hidden values, reset the toggle, and send a decline email.
Yes, essentially this is what I was thinking of. When working with generic fields, you need to use some custom code to apply the generic field values into hidden fields, or to set toggle state in other custom fields. I can help with any Toolset APIs if necessary.

In this case, I'd like to be able to have the hidden values hidden in the backend, is it possible to do that? Even if they are visible but can be collapsed and not in view normally.
A hidden field is not shown in the post editor screen or in the custom field editor screen. It is only shown in the database, and optionally on the front-end of the site if you choose to show it with the wpv-post-field shortcode:
https://toolset.com/documentation/user-guides/views-shortcodes/#wpv-post-field
If you need the ability to manually manage these field values in wp-admin, then you should use a separate custom field group instead of hidden fields. Then you can simply toggle that field group closed in the post editor screen when you don't want to see it.

Second part of my question is how to tie 1 post per user -- any thoughts on how I can achieve that?
I created a separate ticket to discuss this: https://toolset.com/forums/topic/associate-a-post-with-a-user-and-only-allow-user-to-create-that-one-post/

#1110179

Hey Christian,

Thank you for this help -- next question related, hidden fields, where do I find these? I don't see these as an option when I am creating the new fields. Alternatively I can just create a new custom field group, but I'd like to work through both options to really get a sense what will work best for this project.

Thanks!

#1110683

hidden fields, where do I find these?
You won't find them in wp-admin, hence the term "hidden". Hidden fields are stored in the database as raw postmeta values, and managed with code. The general convention is to use a field slug beginning with an underscore.
Get the field value:

$hiddenValue = get_post_meta( $post_id, '_some_hidden_field_slug', true );

Set the field value:

update_post_meta( $post_id, '_some_hidden_field_slug', 'hidden field value' );
#1113820

That sounds like a good plan then Christian. Is there any form validation techniques recommended for Toolset forms? Want to avoid as much additional php processing that needs to be added in if I can.

Thanks!
-Mark

#1113874

There's not much front-end validation available without PHP. Email addresses, numbers, and dates can be validated to some extent, and required fields can be enforced. Beyond that, you'll need the cred_form_validate API and PHP. https://toolset.com/documentation/programmer-reference/cred-api/#cred_form_validate

I just posted an answer in one of your other tickets that shows an example you can work with.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.