Skip Navigation

[Gelöst] Auto-modifying fields after user submits a form

This support ticket is created vor 5 Jahren, 8 Monaten. 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.

Heute stehen keine Supporter zur Arbeit im Werkzeugsatz-Forum zur Verfügung. Sie können gern Tickets erstellen, die wir bearbeiten werden, sobald wir online sind. Vielen Dank für Ihr Verständnis.

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)

Dieses Thema enthält 6 Antworten, hat 2 Stimmen.

Zuletzt aktualisiert von alexG-4 vor 5 Jahren, 8 Monaten.

Assistiert von: Christian Cox.

Author
Artikel
#1209452

I want to build a database-oriented SaS.

One of the main functions will be to create names of objects in a standardised form. I've looked at all sorts of options for technology to do this, but have found nothing that will do this without charging end-users a monthly fee that would be prohibitive for this app. Then I recalled the latest updates in Toolset - advanced post-relationships and drag-and-drop form editor : things that are at the core of what I'll need.

So now I'm checking out the feasibility of using Toolset.

I know I'll be able to achieve anything I want in terms of the look and feel of the app. What I need to be sure of is that I can do the basic "database" work relatively easily. (Shockingly, this is where even MS Access let me down!) So here is a simple example of what I need to achieve.

I have two post types -
Topics: with fields TopicName and Topic
Brands: with field Brand

I created a one-many relationship between Topics and Brands so every Topic can have one Brand. Easy!

I have a "New Topic" form showing two fields:

Topic (enter value) - mandatory
Brand (lookup from post-type Brand) - optional

So, finally, here is my question. What is the best way to achieve the following?

I want to add code somewhere to auto-calculate the value of TopicName (in the Topics post type) as follows:

If there is no Brand selected, then
TopicName = Topic
Else
TopicName = Brand "|" Topic

At its core, my app will have a lot of relationships and 'calculated fields' like this (usually more complex).

So I'm looking for advice on the best way to go about this. (Quite possibly I'm overlooking the glaringly obvious and that this is very easy. I hope so...)

Unless it gets a lot more complicated, I'd prefer to do it without modifying the form code so that I can preserve the very nice drag-and-drop capabilities for future enhancements. But actually ANY solution would be good!

I'm really hoping there's a good answer to this because I'm running out of options. On the other hand, I know that if I CAN do the DB stuff in Toolset without it being overly clunky, I'll be able to make use of the rest of Toolset's awesome features to make this into EXACTLY what I wanted, and probably more than I originally envisioned!

(I may have a follow-up question about doing something at the next level of complexity - which is where MS Access let me down.)

#1209650

Hi, it sounds like you have a one-to-many relationship between Brands (parent) and Topics (child), and you want to allow Users to create new Topic posts using Forms. If the User selects a parent Brand in the Form, you would like to set the new Topic post title to be "Brand | Topic text from form", but if no parent Brand is selected you would like to set the Topic post title using the text entered in the new Topic post form. Am I understanding this correctly? If so, then there are a few other tickets here in the forum showing how the child post title can be set programmatically in the back-end using the Forms API. Modifying the design of the Form using the drag-and-drop filter won't cause any problems here, as long as the parent post select field remains in the Form along with the post content field.

Here's an example that directly copies the parent title to the child title:
https://toolset.com/forums/topic/trying-to-grab-parent-title-to-use-as-childs-title/

add_action('cred_save_data', 'copy_parent_title_to_child',10,2);
function copy_parent_title_to_child($post_id, $form_data)
{
// if a specific form
if ($form_data['id']==429)
{
if (isset($_POST['@member_visitation_parent']))
{
$my_post = array(
'ID' => $post_id,
'post_title' => get_the_title($_POST['@member_visitation_parent'])
);
wp_update_post( $my_post );
}
}
}

I could help you modify that code to work for your needs, if necessary. Note that this approach is on the back-end, meaning that the post title field in the new child post Form will not show the title as the User creates their post.

#1209743

Thanks, Christian

Big picture... I'm now convinced that Toolset is the answer! (As usual...)

Yes - you've understood this example exactly. I stumbled around WP documentation and actually tried something similar to that, using "save_post" instead of 'cred_save_data' : and it didn't work. Good to know that the general approach was right, though.

But when that didn't work for me, I started thinking about other approaches. Specifically, perhaps I don't actually need to store the calculated value? Instead, I can just ensure that, whenever I display the list of Topics (or whatever post-type I'm showing), I just calculate the value on the fly. And with a bit of experimenting, I got that to work. It seems like a good approach, and doesn't need me to write PHP - it can all be done with shortcodes and HTML.

BUT I think I may run into problems....

Topics is the starting point for many other post types: most of the others will need to incorporate a Topic into THEIR name - and so there will be many-to-one relationships from Topics to about 8-9 other post types.

Now, when I create a form for creating those post types and include a "lookup" on Topics, I won't have the nicely constructed Topic Name in the Title field.

So, I think I'm going to have to use the 'backend' method you outlined.

Am I right?

#1210023

Update:

I've almost got this working!

Here is the code I'm using:

add_action( 'cred_save_data', 'update_database', 10, 2 );
function update_database ( $post_id, $form_data )
{
  switch ($form_data['id'])
  {
    case 25: // New Topic
    case 48: // Edit Topic
      $brand = toolset_get_related_post( $post_id, brand_for_topic );
      $topic = get_post_meta($post_id, 'wpcf-topic', true );
      $title = $brand . " | " . $topic;
      $args = array('ID' => $post_id, 'post_title' => $title);
      wp_update_post($args);
      break;
    default:
  }	
}

The only thing not working is that $brand comes up as 0.

I've double checked that brand_for_topic is the slug for the brand-topic relationship.
And I've checked in the Admin area that the related Topics ARE showing up under the relevant Brands - so the relationships ARE being formed correctly.
.
.. So I'm a bit stumped!

#1210110

Oh dear!

That was glaringly obvious now I look again.

Final solution:

add_action( 'cred_submit_complete', 'update_database', 10, 2 );
function update_database ( $post_id, $form_data )
{
  switch ($form_data['id'])
  {
    case 25: // New Topic
    case 48: // Edit Topic
      $brand_id = toolset_get_related_post( $post_id, 'brand-for-topic' );
      $brand = get_the_title($brand_id);
      $topic = get_post_meta($post_id, 'wpcf-topic', true );
      $title = $brand . " | " . $topic;
      $args = array('ID' => $post_id, 'post_title' => $title);
      wp_update_post($args);
      break;
    default:
  }	
}

Also, note that I had to use cred_submit_complete rather than cred_save_data.
cred_save_data worked when I was editing an existing entry, but not when creating one. It seems to make sense to use cred_submit_complete anyway.

#1210113

Okay great, let me know if you run into additional problems with the updated code.

#1210180

My issue is resolved now. Thank you!