[Geschlossen] Produce custom titles for my forms

[Author]

Artikel

[larryL]

Hi Waqar. I'm trying to produce custom titles for my forms. And when I use

add_action('cred_save_data', 'build_radio_form_title', 10, 2);
function build_radio_form_title($post_id, $form_data) {

$forms = array( 18249 );
if ( in_array($form_data['id'], $forms) ){
$radti = get_post_meta($post_id, 'wpcf-radio-titles', true);
$ofti = get_post_meta($post_id, 'wpv-post-author', true);

$post_title=$radti. ' ' .$ofti ;
$slug = sanitize_title($post_title);
wp_update_post(array('ID'=>$post_id, 'post_title'=>$post_title,'post_name' => $slug));

Or something like it for other forms All I get are numbers like -1601539200- instead of the field values. What am I doing wrong?

Thanks!

[Nigel]

Hi Larry

We had a discussion about the volume of support work at our weekly meeting last week as we've been stretched by a high workload recently (we didn't discuss specific tickets or clients), at which the team were reminded of the limits of support.

That is, we can and will offer as much help as is needed to use the product, and that includes describing how to use the official APIs. But it doesn't include writing custom code on behalf of clients, or teaching PHP or the WordPress APIs. If clients need some additional functionality not available within the product that requires the use of the Toolset APIs but are not comfortable with the WordPress APIs and PHP then they should employ a developer who is, and we set up the contractor pages (https://toolset.com/contractors/) to put clients in touch with developers who are familiar with Toolset.

If Toolset is missing some feature that you need we can consider adding it (bearing in mind the timescales involved), but looking at this ticket, that's not relevant here, you want to generate custom post titles based on some field values, which is exactly the kind of task the Forms API is for.

The first problem I see with your code is that the post title is not a custom field, it's a standard field of the post, so you do not retrieve it with get_post_meta, you retrieve the post object using get_post (given that you have the post id).

https://developer.wordpress.org/reference/functions/get_post/

That post object will have the author ID available, but I'm guessing you want the name of the author, which you would need to retrieve using get_userdata().

https://developer.wordpress.org/reference/functions/get_userdata/

As for the field "radio-titles", I'm guessing this is a custom radio field? If you retrieve its value using get_post_meta you will obtain the stored option value, not the option label, which is maybe what you are looking for. For that, you can use the API function types_render_field.

https://toolset.com/documentation/customizing-sites-using-php/functions/

When you are trying to understand why your code doesn't work, it's helpful to print messages—including the values of variables—to your debug log so you can study them and try to understand the output.

If you haven't already, turn on the debug log by editing your wp-config.php file and change the line with WP_DEBUG like so:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

That will create a debug.log file in your /wp-content/ directory which you can examine in any text editor.

In your custom code you can send simple messages to the log like so:

error_log("I got this far in the code");

error_log("radti is $radti";

If you are trying to examine a variable which is an array or an object it is helpful to output them using the following for improved readability:

error_log('myVar is: ' . print_r($myVar, true));

One last observation about development, which you correctly observe is focused on Blocks. Prior to that we found that we had to invest significant resources in maintaining compatibility with an ever-expanding roster of page-builders that our clients were using, so much so that we had very limited resources to improve our own product at the same time as the page-builders improved theirs. There was only one way that could end. So, switching focus to support WordPress's built-in page builder it has freed up resources for us to improve the product, and there have been a lot of enhancements in the last year or more, even if most of them are occuring in the Blocks space.

[larryL]

I'm not going to argue the point that your support staff are overworked. They are. We all are.

I'm going to focus only on the request related to this 'ticket'. I was not asking Waqar (or whomever responded to my chat request) to do any custom work or, as the title of this ticket implies, "Produce custom titles for my forms". All I asked him to do was take a look at the function that I implemented, which is based upon the example(s) provided not just to me in previous support exchanges but also in your documentation (https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data) and see if he could direct me to where in it I might have missed something. I wasn't asking for him to log on to my site, or, create any alternative functions. Debug has been on by default since I started working on this project, which not that it's of any relevance, I'm not being paid for. There are no errors. I was simply trying to figure out why instead of dynamically inserting the custom field value(s) as the title it was inserting a number string - or - what that number was.

I thought that since this was one of your documented functions it would be supported.

I'll leave my feelings on Blocks to another time.

[Nigel]

I spoke about this with the team at our weekly meeting yesterday to make sure everyone is providing the support we should be, which I outlined in my last reply, and I'm sorry that Waqar stopped short of what is expected. I explained in that last reply why your code isn't working, and what you would need to do to fix it, with links to the documentation about the functions you would likely use in this case, and hopefully you have enough information there to make the necessary changes. The debugging tips should help you if you run into problems.

[larryL]

This is not a reflection of Waqar as I feel that he had always gone above and beyond in providing support.

My issue is that I had what I believe to be a reasonable question on an issue I still have with a function Toolset provides. Ironically it's taken longer to have this conversation than to have just looked at the function I posted in chat. IOW, it's taken two of your resources on here plus time in a staff meeting - not to mention my time. I fail to see the upside.

[larryL]

Incidently I did modify the function using your suggestions:

$radti = get_post_meta($post_id, 'wpcf-radio-titles', true);
$ofcti = get_userdata($username, 'wpv-post-author', true);

But it did not make any impact on the results. I read through wordpress's docs on get_userdata and get_post_meta and I made changes to the string and I still do not get values in the newly created post title. So either I have something wrong in my function or there is conflict somewhere else. But there are no debug messages.

[Nigel]

I suggest you confirm that $radti gets something sensible by outputting it to the debug.log, like so:

$radti = get_post_meta($post_id, 'wpcf-radio-titles', true);
error_log($radti);

Depending on what the field type is, you may not want the value stored in the database (which is what get_post_meta will retrieve), you may need the formatted version of the field (e.g. the display label of a radio field rather than the stored value), in which case you should use types_render_field instead of get_post_meta (described above).

I assume for the post author you want their name.

As I described above, starting with the post id, you can get the post object using get_post(). The id of the author is available as $post->post_author, so you can get the user object of the post author using get_userdata. The display name of the author would then be available as $user->display_name.

At each of those steps you can output the results of the function calls to your debug log to see if the results are what you are expecting.

[larryL]

Debug is enabled. No errors are being outputted, I did check on the server.

add_action('cred_save_data','func_custom_radio_post_title',10,2);
function func_custom_radio_post_title($post_id,$form_data) {
    if ($form_data['id']==18249) {
        $radti = get_post_meta($post_id, 'wpcf-radio-titles', true);
			error_log($radti);
        $ofcti = get_userdata( $user->display_name, true);
        $title= $radti. '-' . $ofcti;
        $args = array('ID' => $post_id, 'post_title' => $title);
        wp_update_post($args);
    }
}

Simply generates a post id and no author name.

[Nigel]

Firstly, I would expect something to be sent to your logs, you have an error_log call in there, and if it isn't outputting anything to the debug.log then

1. the debug log isn't turned on, or
2. that code isn't running (because the if condition fails, the id is wrong), or
3. get_post_meta returns nothing, because there is no such field submitted with the form or it is submitted with an empty value

You can determine whether it is 1 or 2 by just sending some text to the log, e.g.

error_log("Boo to a goose");

I'm inclined to think the debug.log isn't turned on, because I'd expect an error on the get_userdata line because you are referring to a $user object that doesn't exist.

You are still not trying to get the post author correctly.

* You have the $post_id available.
* Use get_post() to get the $post object for the post with that id
* The ID of the author is available as $post->post_author
* You get the $user object for the author with that id using using get_userdata( $post->post_author );
* The display name of the author is then available as $user->display_name

[larryL]

Adding a note so thins doesn't get closed.

[Nigel]

Sure, let me just mark as awaiting your feedback so it doesn't sit in my queue.