Hello, it's not clear to my why the post ID would be undefined, but maybe it's because the action is triggered somewhere else on the site besides the single mixologist page? A simple preventative solution would be to add some conditional that prevents the post relationship API from being queried if the post ID isn't defined for any reason:
function my_custom_query2( $query, $widget ) {
$mixologue_id2 = get_post( get_the_ID() ); // Get ID of current mixologist
if( !$mixologue_id2 ) {
return;
}
$cocktail_id2 = toolset_get_related_posts(
$mixologue_id2, // replace this with the child post id
'mixologist-cocktail', // slug of the post relationship
'parent', // get posts where 12345 is the child post ID
1000000, 0, // pagination
array( ),
'post_id',
'child'
);
$query->set( 'post__in', $cocktail_id2);
}
Otherwise, the post ID may be available in the callback arguments of this function:
function my_custom_query2( $query, $widget ) {
You could use PHP logging to find out what exactly $query and $widget represent. The post ID may be buried in the data structure of one of those variables.
function my_custom_query2( $query, $widget ) {
error_log('query:');
error_log(print_r($query, true));
error_log('widget:');
error_log(print_r($widget, true));
...
Whenever the function executes, the log will show you the structure of data included in those two parameters. My guess is $query includes some information about the current post ID somewhere, but the structure of that information isn't clear without some logging. Elementor 's support team might be able to help you with that, since the action seems to be related to elementor:
add_action( 'elementor/query/maquery2', 'my_custom_query2', 10, 2 );
Their documentation would/should include information about the parameters available in a callback.
If you're not familiar with turning on logs, I can show you how to activate them in a typical wp-config.php file. Go in your wp-config.php file and look for
define('WP_DEBUG', false);
Change it to:
define('WP_DEBUG', true);
Then add these lines, just after the WP_DEBUG line:
define('WP_DEBUG_LOG', dirname(__FILE__) . '/error_log.txt');
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define('WP_DISABLE_FATAL_ERROR_HANDLER',true);
If this causes an error, it's likely that your wp-config.php file already contains one of these definitions. Comment any duplicate definition out so the definition I provided is not duplicated to cause an error. Then save the wp-config.php file back to your server and load the page with the widget again. You should now find an error_log.txt file in your site's root directory. Use FTP to look for this file in the same directory as wp-config.php. You may need to click "Refresh" in your FTP browser to see a new file appear. Please download this file to your computer, open it in any text editing software, and review its contents. If it's not clear where to find the post ID, you can share the output with me in your next reply. Once that is done, you can revert the changes you made to wp-config.php and delete the log file using FTP.
