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.
