[Resolved] Split: Using checkboxes when not a Types field

[Author]

Posts

[markR-11]

Thank you Nigel, that helps!

I am trying to make a separate ticket (but connected to this), but keep getting an nginx 500 internal server error upon submission. The issue is related to this workflow, so I am going to add it here.

Our idea to move away from taxonomies seems to work, and for now, not noticing any sluggish performance. I am now working through the review page that administrators see to compare the the current post with the 'new post'. My next hurdle in this workflow is here:

I am working with both defined custom fields of a custom post type (added in Toolset / Custom Fields section), as well as hidden custom fields (marked as _wpcf-slug-name, added through hooks after a form is submitted). This is done using a CRED form, that when submitted, is hooked to prevent the main custom fields from being updated, instead updating these hidden custom fields (_wpcf-slug-name). A view is then set up to show differences between custom fields and hidden custom fields on a page allowing for approval.

This works fine for non-checkbox/select fields, where I use "wpv-post-field name="_wpcf-slug-name"" to access the field. But for 'checkboxes' fields, the data is returned looks like the screenshot attached (references to the checkbox option, but not a clean list of the options). Instead, I want the data to be displayed similarly to if I used "types field="slug-name"""/types", whereby select/checkboxes options will show in a comma separated list.

Link to a page where the issue can be seen: Page isn't public, but see screenshot below. That is the output using "wpv-post-field name="_wpcf-slug-name"". Note that attempts to use a types shortcode here failed. I even tried to rename the meta_key in the DB to be 'wpcf-pending-slug-name', but that did not work with the types shortcode (using 'pending-slug-name' as the field value).

Thank you,
Mark

[Nigel]

Hi Mark

The problem here is that once you start making copies of Types fields but using a different post meta key, they are no longer Types fields.

For many fields that doesn't matter, because they are stored as simple strings.

For checkboxes fields it very much does matter, because they are stored as serialised arrays in a proprietary format.

So, rather than using _wpcf-slug for your ghost fields, you should perhaps use an alternative convention, such as wpcf-slug-ghost, and you would actually have to duplicate such fields themselves in Toolset > Custom Fields. You would want to collect them in a field group which you don't show anywhere, but by making them actual Types fields you will be able to use them and output them just as with the original fields.

[markR-11]

Okay that sounds like a plan to me -- any options on how to hide these from the admin side of things? I wouldn't want admins to normally see these outside of the view we built (just to ease confusion).

The only other issue I am thinking of is how I can update the live/production checkbox options from the 'review/hidden' options, after approval? I was simply copying the value of one field to another (_wpcf-slug-name to wpcf_slug-name) using update_post_meta(), but I am thinking this might pose a problem for the checkbox options because they seem to reference other options. Is there another way to do this using the 'normal/name-friendly' versions of the selected options?

Thanks,
Mark

[Nigel]

Hi Mark

It's actually a little ugly trying to copy across values from one checkboxes field to another.

I have an alternate idea which I'm going to set up a test for now, and which would allow you to continue with taxonomies etc. as you were before, so you may want to wait for my next update if you are working on this now.

[markR-11]

That's excellent Nigel, thank you. Please let me know how you make out with that, and if that is a more viable option.

Regards,
Mark

[Nigel]

OK, because of how checkboxes fields are stored it is not practicable to copy the values from one set of checkboxes to a different set of checkboxes, even if the options are set up identically apart from the name/slug. (We have an internal ticket to completely rewrite checkboxes fields, but that doesn't help us right now.)

So my thinking was to go back to something closer to the post revisions idea mentioned previously.

Instead of using actual WordPress post revisions (which support neither custom fields nor taxonomies), mimic them and handle the updates manually.

I forget what post type you are working with, but say it is 'project'. Create a 'version' post type as well, and whatever field groups and custom taxonomies you have available to projects, make them available to version posts, too. (When you have this all set up and working, you can uncheck the "show_ui" option for the version post type so that the posts are not shown in the backend.)

The idea is that when a user edits their project with a Form, instead of updating the project a duplicate post of the type version is created with the new values coming from the form submission. It would mirror the project post, and because it is itself a post, it can have custom fields and taxonomies (the same fields and taxonomies as project post, but possibly with different values).

Your site admins can then compare the current project post with the proposed changes shown in the version post, and if they accept them you can effectively do the reverse, and copy over the fields from the version post to overwrite those in the project post, then delete the version post.

It might not be necessary (because the posts would have the same author and each user is allowed only one project post if I understand correctly), but it could make sense to use the relationships API to make a one-to-one connection between the project and version posts that could prove helpful.

I think that would be an optimal way to proceed.

I ran into a number of obstacles trying to get an example of this to work.

My preferred option was to trick the CRED edit forms so that before the form submission was processed we changed the ID of the post being edited from the actual project being edited to a version post we create, so that the original post was untouched, and the Forms code did all the work of taking the form inputs and storing the corresponding post meta and assigning terms as required. Unfortunately that proved impossible.

So, the alternative that I suggest you try and implement would be to adopt a similar approach with the version posts, and use the cred_before_save_data hook to intercept the form submission before the project post fields are updated with the form content.

You will need to unset any field in the $_POST object that you do not want to get updated in the project post (you cannot simply delete $_POST or the form won't work, so you will unset($_POST['post_title']); etc. for each field).

Create a new version post (using wp_insert_post), and then set the post meta and taxonomies based upon the form fields (available in $_POST). Use toolset_connect_posts (https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_connect_posts) to connect the project to the version posts if that seems helpful.

When the form submission is complete you should have your original project post intact, and a duplicate of this as a version post with the fields updated according to the edit form submission.

You'll then have some basis to compare the two and decide whether to accept the changes. If so, you'll run a code snippet to copy the fields from the version post across to the project post, before disconnecting and then deleting the version post.

That is a fair sized undertaking, which wouldn't be so effortful if WordPress revisions supported custom fields and taxonomies.

The alternative is to simply change the post status to Pending Review when the post is edited, which will mean it going offline until it is approved.