[Resolved] Manipulate CPT Custom Taxonomies on form submit

[Author]

Posts

[markR-11]

Tell us what you are trying to do? I am providing users the ability to update a posting of theirs. This can be thought of as a directory listing, in which the user can have only one. View is set up to show a form to add the post if they do not have one, and if they do have one, the view instead shows a form to update it.

I want any update of the listing by the user to have to be approved, so what I am doing is using a custom action added to my functions file to intervene before the data is saved to the database. This way, their previous post stays active while this is under review. I am working on having a view/form built for the admins which would show any posts with updates that should be reviewed, and then allow it to be approved or declined.

This works fine for most custom fields, but not working for custom taxonomies associated to the post. I am trying with the following code, but it never gets triggered on the taxonomies. How do I do this with custom taxonomies I have created for these custom posts? This is what I am doing for custom fields:

add_action('cred_before_save_data', 'my_before_save_data_action',10,1);
function my_before_save_data_action($form_data)
{
    // if a specific form
    if ($form_data['id']==1116)
    {
	$fieldArray = array('first-name','last-name','phone','email','website','location','address-2nd-location','address-3rd-location','facebook','twitter','linkedin');
		foreach ($fieldArray as $fieldName){
        	if (isset($_POST['wpcf-' . $fieldName]))
        	{
        	    // remove this field data
	            update_post_meta( $form_data['container_id'], '_wpcf-'. $fieldName, $_POST['wpcf-' . $fieldName] );
				unset($_POST['wpcf-' . $fieldName]);
        	}
    	}
	}
}

Is there any documentation that you are following?
This is a continuation of this thread that Christian helped with: https://toolset.com/forums/topic/require-approval-for-user-submitted-post-type-directory-listing-after-edit/

Is there a similar example that we can see? Not particularly, but check out the other ticket, and I can provide more detail, or get on a call.

What is the link to your site?
hidden link

[markR-11]

Please relabel this ticket: Manipulate CPT Custom Taxonomies on form submit

[Nigel]

This is tricky.

I read through your earlier linked thread.

You have a viable solution with custom fields because there exist hidden custom fields within WordPress, so you can effectively create a ghost version of the post and its fields.

But there is no such concept with taxonomies, and taxonomies are stored in custom tables and I don't think it is readily possible to mimic what you can do with custom fields with taxonomies.

I need to think about this some more, so I'm just replying for now to say I'm on it and will get back to you.

[Nigel]

Hi Mark

I don't think this is possible for taxonomies without a very contrived solution that would involve modifying queries to hide the "ghost" taxonomy terms everywhere else in your WP installation.

I'm guessing your solution with custom fields must already be fairly contrived in terms of how the administrators check the updated post and then publish the changes.

There is no avoiding the fact that you will essentially need to roll-your-own solution.

Given that I would go about it differently.

I would use the WordPress post revision functionality.

You could modify your workflow so that when a user edits their post rather than edit the post itself you generate a post revision (an alternate version of that post).

Your administrators can then look at the post revision—even comparing it to the current version—then "restore" that revision so that it becomes the published version.

Post revisions are stored in wp_posts with post ids, so you can attach post meta to them (so different versions of the same post can have different custom field values) and, crucially in your case, they could have different taxonomy terms assigned to them. There shouldn't be any side effects, such as the post revisions appearing in a taxonomy archive, because post revisions are a built-in WP feature and such posts are not included.

So, what are the problems with this approach?

Well, first, you have to handle creating the post revisions programmatically when the edit form is submitted, though that shouldn't be too difficult.

The problem is that post meta and taxonomies are not supported by post revisions, which basically just store alternate versions of the post itself (i.e. the post title and post content).

So you would have to also manage handling the custom fields and taxonomies when switching between post revisions.

(There is a very old project to add support for custom fields to WP core which never happened, but you can check out the feature plugin here: https://wordpress.org/plugins/wp-post-meta-revisions/, which you could test, and use for inspiration when adding support for taxonomies.)

For a primer on post revisions see hidden link.

It would be quite an undertaking—it's beyond the support I can offer here—but it is the only solution I think is viable for including taxonomies, and would offer the best workflow.

You could try the Toolset contractors to see if anyone was able to quote for such work: https://toolset.com/contractors/

[markR-11]

Hey Nigel,

Really appreciate the thought around this and depth of response. I was concerned this might be the case.

I might be able to avoid all of this based on your thoughts around this question: We are not bound to using taxonomies I don't think. What negative impacts do I have in terms of search functionality (you've seen the search page) or any other factor if I were to switch away from the taxonomies for this custom post-type, and instead add each of those taxonomies as custom fields to the custom post type (set of checkboxes)? I am just thinking that in this case, we could simply follow the same workflow of copying updates to hidden fields, and then using a processor on the approval form to copy them over to the production/live fields when approved.

The one thing that pops to mind is that select boxes we use on the search page need to now be bound to all of the available options on a checkbox custom field type -- how can we do this?

Just for your added context, we will only ever access these posts types through the search page (which currently lets us filter on the taxonomies), and the page of the post itself. We will not be showing other archiving at all. Sorts on the search page will be based on name/proximity.

Thanks as always,
Mark

[Nigel]

Hi Mark

It shouldn't really be an issue switching to custom fields from taxonomies, unless this is a very large site or you are hitting the limits in terms of your hosting.

Taxonomies are optimised for queries in a way that custom posts are not, so if you are going to filter posts by something, if it makes sense you should always opt for taxonomies over custom fields.

That said, you would only notice the difference on large sites. If yours is, let's say, an average sized site then I doubt you would see an appreciable difference.

For checkboxes custom fields you shouldn't save zero to the database for unchecked fields, we need to refactor the code for checkboxes fields to avoid that particular setting tying us up in knots. (There is a note to that effect in the documentation, but I can't put my hands on it right now.)

[markR-11]

Got it - this site has ~2500 users -- where would you put that in terms of size?

Do I need to do anything special so that the search select boxes can pull the list of checkbox options from the custom post type/field group?

[Nigel]

Sounds like a medium-sized site.

Much will depend on site-specific things and your server resources, so the only way to really know is to create a test and see.

Make some test profiles, add custom fields to them in place of the taxonomies, create an equivalent View which includes filtering by the custom fields, and try it out. See whether the difference in performance is noticeable. (I'd be interested to know how that works out on your real-world site.)

[markR-11]

Thanks Nigel, we'll be working on this tonight. My second question based on this, do you know of anything special we need to do so that the search select boxes can pull the list of checkbox options from the custom post type/field group? With taxonomies there was no extra work involved.

Thanks,
Mark

[Nigel]

Hi Mark

When you insert a filter control for a custom field that has options (such as a select field or checkboxes field) then the default should be to display all of those options in the filter control on the front end.

You can check the settings as per my screenshot to make sure it is not set to only show available options (meaning only those that have matching posts returned by the View).

[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

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

https://toolset.com/forums/topic/split-using-checkboxes-when-not-a-types-field/

[markR-11]

Adding a screenshot seems to fail for some reason (HTTP_ERROR), so copy and pasted the output I get from those checkbox field options below:

wpcf-fields-checkboxes-option-e407b83ebbb54b2f3ec0e99b862811b3-1, wpcf-fields-checkboxes-option-3a0f06cefd46bcfd2ddeea7b4601a648-1, wpcf-fields-checkboxes-option-2e44bd64ff636ab8e307c0d321a00027-1, wpcf-fields-checkboxes-option-5707195e051dcce7f1c8adb8595589c4-1

[Nigel]

Hi Mark

Sorry, we have some technical issues with the forum that will hopefully be resolved tomorrow.

I've split your latest question into another thread, and will reply there.

[markR-11]

Awesome, thanks Nigel!

[Nigel]

OK, closing here.