Conditional Tag: Multiple Conditions

• Shortcodes, like HTML, are a markup language, not a programming language.
• This means they do not support all logical operators, as shortcodes are strings processed with regular expressions, not a tokenizer.
• It’s a pedantic difference, but in a Pods context, this means no: if you need behaviors of a programming language, use a programming language. The easiest API for this in WordPress is defining a custom shortcode, which is one function, has existed since WordPress 1.2, and is supported by all templating engines and WP page builders.
• As far as I know, Jory’s suggestion will not work both because Pods does not process shortcodes recursively (they cannot be nested), and because an if within an if would constitute a logical AND, not a logical OR.

The easiest solution, defining a custom shortcode for use in your template, would look like this:

<?php
/**
 * @see https://codex.wordpress.org/Shortcode_API
 * @see https://en.wikipedia.org/wiki/Ward_Cunningham
 */
add_shortcode(
	'cunninghams-law',
	function( $atts, $content, $tag ) {

		if (
			empty( get_post_meta( get_the_ID(), 'custom_field_1' ) )
			|| empty( get_post_meta( get_the_ID(), 'custom_field_2' ) )
		) {
			return '';
		}

		$pod = pods(); // Defaults to current post type and post ID.

		ob_start();

		?>
		<div>
			<h1>Headline</h1>
			<?php $pod->display( 'custom_field_1' ); ?>
			<?php $pod->display( 'custom_field_2' ); ?>
		</div>
		<?php

		return ob_get_clean();
	}
);

It is worth noting that this approach has used both Pods and the WordPress core functions for accessing field values. Some general notes:

• The above example would output the desired HTML or nothing (a blank string) for the shortcode [cunninghams-law]
• A shortcode callback (the function) must always RETURN output, not print or echo. Both return and an output buffer (ob_...) have been used to illustrate various ways to do this.
• Pods fields will usually be stored in post meta. For illustration purposes, get_post_meta() has been used, while output is still ->display(). This is because your example used magic tags, which would use Pods default output formatting, which would be the same as ->display() in PHP. The way to get a raw field value with Pods is ->field(). The Pods functions will run convenience connectors for various field types, while WordPress core functions may vary between functions related to post meta, taxonomy term meta, taxonomy term objects, user objects, and user meta etc.
• || means “OR”.
• While it is technically possible to jump from PHP back into a Pods template syntax for use of magic tags, it really does not make sense to do so. If one understands enough code to know how to do that, one also then generally understands that it’s better to output templates from PHP, especially if one has already jumped into a PHP context. So it’s possible, but generally not advisable.
• In the above example, I have output the template by capturing output into a buffer and escaping from PHP into HTML several times. https://www.php.net/manual/en/function.sprintf.php without output buffering or https://www.php.net/manual/en/function.printf.php with output buffering is generally a better way.