tribe_dynamic_help_text is not defined

Preface and Rant
While I understand closing tickets for inactivity (here), you can likely understand my disdain for you not resolving a problem and pretending it’s fine.
So I won’t say thank you in regards to the specific error.
However I am pleased you offer a button to enable Debug mode, despite your lack of documentation on the define('SCRIPT_DEBUG',true); aspect. Had to find that in your code.

If you guys aren’t deprecating entire api functions, or dropping fields from objects, it’s one thing or another with this plugin. Frustration level 9000.
I have had to dig into your internals and debug this for hours to figure it out.

So for others out there looking for help where none is provided, the answer follows.
please excuse my candor as it’s directed towards the lackadaisical staff of this product, with whom I pay for the Pro version on several websites.
And NO, sir staff member, this is NOT related to the pro version, it’s related to the free version. So don’t close this on a political/procedural basis and tell me to go post this in your support portal.
This issue is for SPECIFICALLY, the latest version of your FREE product on the latest version of wordpress, on ANY version of PHP (5.6 all the way to 7.3).

IT IS NOT a typo.
As the previous thread summarized, though that seems accurate looking at the javascript file at face value. What a strange combination of globals and instance variables, mixed together with similar names (not talking about the .min file either).
GREP scan reveals the truth.

They are using PHP to procure a wp_localize_script with that name.
But in this error scenario – it runs on admin only, not on front end. So it globally does not exist on page output.
The question became why. My first guess was Cornerstone since it’s a dynamic system.
The issue causes a “soft” onload error on front end, and literally breaks the editor for Cornerstone from even loading in backend (since it uses an iframe of the frontend).

Digging deeper
get_js_dynamic_data is not executed on front end, but it is on backend.
As confirmed by injecting error_log() calls into key spots in the code.
This leads us to tribe_asset in the general.php file. Thus, to the register() function of the Assets.php file.
Our issue is with the $arguments parameter, which is an array containing a key value pair for ‘localize’. Leading us to the function parse_argument_localize().
Here, get_js_dynamic_data was confirmed to be in the array of scripts being localized.
The json_encode dump looked precisely the same between admin and front end.
Which takes us back to square one.

Using a debug_backtrace on the get_js_dynamic_data, the actual execution is performed by common/Assets.php line #251, under the enqueue function, via call_user_func.
Leading us to find line #225:

if ( ! $enqueue && ! $must_enqueue ) {
   continue;
}

As determined by the []conditionals call_user_func for should_enqueue_on_tribe, returning False.
Which takes us back to the src/Tribe/Assets.php file which has a function called should_enqueue_on_tribe. Which leads us to both should_enqueue_frontend and should_enqueue_admin.

Which leads us to discover that tribe_is_event_query(), tribe_is_event_organizer(), tribe_is_event_venue(), and has_shortcode( $post->post_content, 'tribe_events' ) are all false.
But it’s definitely a POST page.
Begging the question, why is the page loading tribe events at all, if it does not involve tribe events via a shortcode? And why might it not have the tribe_events shortcode?

WELL. As it turns out, has_shortcode() may not detect Cornerstone content-based shortcodes, as Cornerstone must be evaluated and executed.
And it certainly doesn’t check for additional 3rd party or custom shortcodes.
It’s hardcoded.
And there’s the reason. Events Calendar expects standard wordpress content in the post, with the single built-in shortcode: [tribe_events]. No exceptions.

All the above of which anyone with a half decent interest in resolving the problem at your company could have performed & found, far easier than me – having never seen your code before. But I digress.

The Fix
as per this article, add to functions.php:

add_filter('tribe_events_assets_should_enqueue_frontend','fix_tribe_for_cornerstone_and_3rdparty', 10, 1);
function fix_tribe_for_cornerstone_and_3rdparty($should_enqueue) {
    if (!is_admin()) {
		$check = array(
			'tribe_events',
			// add your custom or 3rdParty shortcodes here
			'ecs-list-events',
		);
		global $post;
		if ($post instanceof WP_Post) {
			// run standard logic first for speed..
			foreach($check as $shortcode) {
				if (has_shortcode($post->post_content, $shortcode)) return true;
			}
			// otherwise, check cornerstone content..
			if (function_exists('CS')) {
				foreach($check as $shortcode) {
					$finder = CS()->component('Shortcode_Finder');
					$finder->process_content( $shortcode, $post->ID );
					if ($finder->has( $shortcode )) return true;
				}
			}
		}
    }
    return $should_enqueue;
}

Or …. events calendar staff could add a function_exists() check for Cornerstone to their should_enqueue_frontend code, in src/Tribe/Assets.php, and officially fix the issue. As well as a filter hook and a for loop to process shortcodes in a way that isn’t hardcoded to the single “[tribe_events]”.

GOOD DAY SIR…..
In the voice, dialect, and precisely quoted words of Willy Wonka.
2 hours and 48 minutes lost to never be recovered.

The page I need help with: [log in to see the link]