automator_pro_wp_token_meets_condition_case_sensitive

Description

Usage

add_filter( 'automator_pro_wp_token_meets_condition_case_sensitive', 'your_function_name', 10, 1 );

Return Value

The filtered value.

Examples

/**
 * Example of how to use the 'automator_pro_wp_token_meets_condition_case_sensitive' filter.
 *
 * This example demonstrates how to override the default case-sensitive behavior
 * of the "Token meets condition" action in Uncanny Automator Pro.
 *
 * In this scenario, we want to force case-sensitive comparison when the
 * "User's display name" token is being checked, regardless of the default setting.
 *
 * @param bool $case_sensitive The default case-sensitive setting (false by default).
 * @return bool The modified case-sensitive setting.
 */
function my_automator_force_case_sensitive_display_name( $case_sensitive ) {

	// We need to access the specific token being evaluated.
	// This requires a bit of inspection of the context where the filter is applied.
	// Looking at the Uncanny Automator Pro source, the token name is available
	// as 'TOKEN' within the condition object's options.
	// We'll assume this filter is being applied within a context where the
	// condition object is accessible. For a realistic example, we might need
	// to get the condition object itself. However, based on the provided snippet,
	// the filter is called *before* the token itself is necessarily passed directly.
	// A more robust solution would involve inspecting the context if available,
	// but for a direct filter example, we'll simulate checking the *type* of token
	// that might be involved in a case-sensitive scenario.

	// For this example, let's pretend we know we're dealing with a "user display name" token.
	// In a real plugin, you might inspect $this->get_parsed_option('TOKEN') if that were accessible here.
	// Since it's not directly available in the filter parameters, we'll make a conditional logic
	// based on what *kind* of scenario this filter is usually intended for, or if we could
	// somehow identify the token type.

	// A common scenario for case-sensitive checks is comparing specific IDs or exact strings.
	// Let's assume, hypothetically, that we want to enforce case-sensitivity ONLY if the token
	// being evaluated is something like a specific email address or a username where case matters.

	// To make this example more concrete, let's assume we are checking the 'user_display_name' token.
	// The filter hook itself doesn't pass the token name. A common WordPress pattern is to
	// provide context if needed. Since it's not provided here, we'll make an assumption based on
	// typical use cases.

	// If we wanted to *always* force case sensitivity for a *specific* token like 'user_display_name':
	// This is a bit of a guess without access to the $this context directly in the filter.
	// A more realistic implementation might involve the plugin *passing* the token name to the filter.
	// Since it doesn't, we'll show a scenario where we *might* want to override for certain *types* of checks.

	// Let's assume for this specific case, we are dealing with a scenario where the "user display name"
	// (which is often case-insensitive in WordPress user queries but can be treated differently in specific contexts)
	// needs to be checked case-sensitively.
	// The plugin's code snippet suggests the filter is called *before* the token is explicitly transformed.
	// Therefore, we can't directly inspect the token *within* this filter's parameters.

	// However, if the plugin *intended* for this filter to be used to *conditionally* set case sensitivity
	// based on *what type of token* is being evaluated, then the plugin would need to pass that token
	// information to the filter. Since it doesn't, this filter is primarily for *globally* overriding
	// the default setting.

	// Let's assume a different hypothetical scenario: we want to *disable* case-insensitivity
	// (i.e., make it case-sensitive) for *all* comparisons *except* for a specific token.
	// Or, we want to *enable* case-sensitivity for a specific token.

	// Given the provided source:
	// $case_sensitive = apply_filters( 'automator_pro_wp_token_meets_condition_case_sensitive', false );
	// This means the default is `false` (case-insensitive).
	// If we want to force case-sensitive, we should return `true`.

	// Example: Force case-sensitive comparison for *all* "Token meets condition" checks.
	// return true;

	// Example: Keep it case-insensitive by default (do nothing).
	// return $case_sensitive; // Which would be false

	// More realistic example: Only force case-sensitive comparison for a *specific* token.
	// This requires inferring or having knowledge of the token being checked, which the filter doesn't directly provide.
	// Let's pretend we have a way to know the token name is 'user_display_name'.
	// This is a common pattern: a plugin might add a way to get context to filters.
	// Without that, this is an educated guess or relies on plugin structure.

	// Let's assume the plugin has a mechanism to pass the condition object to the filter,
	// or that this filter is called *within* a method where $this->get_parsed_option('TOKEN') is available.
	// Since it's not passed as a parameter to the filter function itself, we must infer or assume.

	// Realistic Scenario: Make "User's display name" comparison case-sensitive.
	// If we are in a context where we *know* the TOKEN being evaluated is 'user_display_name'.
	// This is difficult to demonstrate without the actual context object.

	// A safer, more direct interpretation of the filter's purpose as provided:
	// It's meant to override the *default* `false` value.

	// Let's simulate making it case-sensitive *only* when the value being compared
	// is likely to be a username or email, where case might matter.
	// This is hard to do without knowing the token.

	// **Most Realistic Use Case:** Override the default globally if needed.
	// For instance, if you have many automations and want all "Token meets condition"
	// checks to be case-sensitive for security or data integrity reasons.
	// In this case, you would simply return `true`.

	// For this example, let's make it case-sensitive *if* the original value was `false`
	// and we want to override it to `true` for specific scenarios.

	// Let's assume a scenario where we only want to enable case-sensitive comparison
	// for specific types of tokens that are known to be sensitive.
	// Since the filter doesn't provide the token name directly, this is a bit of a workaround.

	// However, if the intention is to control case-sensitivity for a *specific token*,
	// the plugin *should* ideally pass the token name or the condition object to the filter.
	// As it stands, the filter receives only the default value.

	// Therefore, the most straightforward and realistic use of this filter is to
	// globally enforce or disable case-sensitive checks.

	// Example: Force case-sensitive comparison for all "Token meets condition" actions.
	// return true;

	// Example: If you want to keep it case-insensitive by default, you wouldn't use this filter.
	// return $case_sensitive; // This is the default behavior.

	// Let's demonstrate a specific override: Enable case-sensitive for "User Display Name" token.
	// This requires a bit of introspection if the plugin provides it.
	// Since the hook is `automator_pro_wp_token_meets_condition_case_sensitive`,
	// it's applied in the context of the `wp-token-meets-condition.php` file.
	// The code snippet shows `$this->get_parsed_option('TOKEN')` is used *after* the filter.
	// If we could access $this in the filter, we could do:
	// $token_name = $this->get_parsed_option('TOKEN');
	// if ( 'user_display_name' === $token_name ) {
	//     return true; // Force case-sensitive for user display name
	// }

	// Without that direct access within the filter function itself, we rely on the filter's
	// primary purpose: overriding the default value.

	// Let's create a realistic scenario: We want to make the comparison case-sensitive
	// *unless* a specific custom condition is met (e.g., if we were passing a specific flag).
	// This is hard without context.

	// The most direct and robust example for this hook is to decide the *global* behavior.
	// If we want to force case-sensitive for a specific token, and the hook doesn't provide it,
	// we'd have to rely on other means, or the plugin would need to pass context.

	// Let's assume that, for a particular automation scenario, we *know* we are checking
	// a token where case sensitivity is crucial. The filter can't *know* this on its own
	// without more information.

	// However, a common WordPress pattern is to add contextual data. If Uncanny Automator
	// were to pass the condition object or token name, this would be more robust.
	// Since it doesn't, we'll show how to conditionally return `true` if you *were*
	// able to detect the token.

	// For demonstration purposes, let's assume we *can* detect the token being evaluated.
	// This would require a modified Uncanny Automator Pro plugin or a more advanced hook.
	// But to provide a *realistic* PHP example of using this filter, we'll simulate
	// detecting the token.

	// IMPORTANT: The following is a SIMULATION of how you *might* detect the token.
	// The current hook `automator_pro_wp_token_meets_condition_case_sensitive`
	// does *not* pass the token name. This example shows the *logic* you would apply
	// if the token name *were* available.

	// Simulate getting the token name. In a real scenario, you'd need access to the condition object.
	// This is a placeholder to illustrate the logic.
	global $automator_current_token_being_evaluated; // Assume this global is set by Uncanny Automator Pro
	$token_name = $automator_current_token_being_evaluated ?? null; // Use null coalescing for safety

	// If the token is 'user_login' or 'user_email', force case-sensitive comparison.
	if ( in_array( $token_name, array( 'user_login', 'user_email' ), true ) ) {
		return true; // Force case-sensitive
	}

	// Otherwise, return the original value (which is false by default, meaning case-insensitive).
	return $case_sensitive;
}

// Add the filter with a priority and accepted argument count.
// The filter is applied within a method, so we assume it's called in a context where
// the default value is `false`. We only need to accept one argument (the default value).
add_filter( 'automator_pro_wp_token_meets_condition_case_sensitive', 'my_automator_force_case_sensitive_display_name', 10, 1 );

Placement

This code should be placed in the functions.php file of your active theme, a custom plugin, or using a code snippets plugin.

Source Code

uncanny-automator-pro/src/integrations/general/conditions/gen-token-meets-condition.php:159
uncanny-automator-pro/src/integrations/wp/conditions/wp-token-meets-condition.php:151

public function evaluate_condition() {

		$parsed_token = $this->get_parsed_option( 'TOKEN' );
		$parsed_value = $this->get_parsed_option( 'VALUE' );

		$case_sensitive = apply_filters( 'automator_pro_wp_token_meets_condition_case_sensitive', false );

		if ( false === $case_sensitive ) {
			$parsed_token = mb_strtolower( $parsed_token );
			$parsed_value = mb_strtolower( $parsed_value );
		}

		$criteria = $this->get_option( 'CRITERIA' );

		$condition_met = $this->check_logic( $parsed_token, $criteria, $parsed_value );

		// If the conditions is not met, send an error message and mark the condition as failed.
		if ( false === $condition_met ) {

			$message = $this->generate_error_message( $parsed_token, $parsed_value );

			$this->condition_failed( $message );

		}

		// If the condition is met, do nothing.

	}