• Auto output selection must be “Meta Start”, “Meta End”, or “Meta After” (meta after only for Jobs)
• If you are using “additional outputs” the output for Overview (auto output) must be the main output (not the one selected in additional outputs)
• Enable Full Wrapper
• Enable Value Wrapper
• In “Output Classes” field, enter in the Font Awesome icon classes to use (ie fas fa-phone)

https://fontawesome.com/v5/search?m=free

You may need to talk to the theme developer to find out WHAT version of Font Awesome is used in your theme, the link above is for version 5 icons.

Below you can find details of this new shortcode, including the available arguments/attributes, and examples of how to use.

[each_custom_field]

This shortcode is meant for outputting any field that has “multiple” values for a single meta key (including resume repeatable fields).  The purpose of this shortcode is to allow you to customize how a multiple field value is output, using shortcodes inside a text widget or some other area of your site that supports shortcodes.

Attributes

key – required the meta key for the field you want to output

listing_id – optional if you want to output for a specific listing, use this to specify the listing ID, otherwise it will be automatically detected

Interior Shortcodes

Interior shortcodes are shortcodes that can only be used inside of the [each_custom_field] shortcode.  These allow you to output the value of the field (or value of a repeatable sub-field).  These shortcodes will not work outside of the [each_custom_field] shortcode.

[value] – will output the value of the field in the current loop (of each field value)

[each_custom_field_value] – used to loop through any resume repeatable field sub-values.  This will ONLY work for resume repeatable fields, do not try to use this for any other field type.  More details and examples can be found below.

Examples

This is a basic example using job_category:

[each_custom_field key="job_category"]
Category: [value]
[/each_custom_field]

You can also combine this with the [if_custom_field] (documentation) shortcode, to only show content when there is a value for that field (if using HTML does not work, make sure to switch to “text” to prevent editor from converting html thinking you want to “show” the HTML on the output):

[if_custom_field key="job_category"]
<ul>
[each_custom_field key="job_category"]
<li>[value]</li>
[/each_custom_field]
</ul>
[/if_custom_field]

Using with Resume Repeatable Fields

In order to use this shortcode with resume repeatable fields, you must use the [each_custom_field_value] shortcode mentioned above.  This will be used instead of the [value] shortcode, as resume repeatable fields are stored with a “key” instead of just the value like all other multiple field values are.  You will still use the [value] shotcode to output the actual value, but inside of the [each_custom_field_value]

[each_custom_field key="candidate_education"]
[each_custom_field_value key="location"]Location:[value][/each_custom_field_value]
[each_custom_field_value key="qualification"]Qualification(s):[value][/each_custom_field_value]
[each_custom_field_value key="date"]Start/end Date:[value][/each_custom_field_value]
[each_custom_field_value key="notes"]Notes:[value][/each_custom_field_value]
[/each_custom_field]

[each_custom_field key="candidate_education"]
[each_custom_field_value key="location"]Location:[value][/each_custom_field_value]
[each_custom_field_value key="qualification"]Qualification(s):[value][/each_custom_field_value]
[each_custom_field_value key="date"]Start/end Date:[value][/each_custom_field_value]
[each_custom_field_value key="notes"]Notes:[value][/each_custom_field_value]
[/each_custom_field]

When using the [each_custom_field] to output resume repeatable fields, only the values you specify with the [each_custom_field_value] will be output.  If there is no value for that specific field, nothing will be output (meaning the text inside will only be output when there is a value).

Tips and Tricks

Removing Line Breaks or Excess Spacing

By default when you use shortcodes, or a WordPress editor, it “automatically” adds paragraph tags sometimes to the output, which can result in extra line breaks.  If you want to remove this, it’s as easy as just updating your shortcode code to remove the line breaks you have in it.  My suggestion is to first make sure it outputs the values you want, then you can remove the line breaks and white space.  As example, for the basic example above, to remove the line breaks just change it to this:

[each_custom_field key="job_category"]Category: [value][/each_custom_field]

https://wpjobmanager.com/document/template-overrides/

If you want to customize any of the form field templates (template for field types), please see this link for documentation on that:
https://plugins.smyl.es/docs-kb/using-custom-template-overrides-for-input-fields/
–

For the Packages addon the override directory should be jm_packages instead of job_manager

For Resumes addon the override directory should be wp-job-manager-resumes instead of job_manager

UNDER CONSTRUCTION

Changes

• Added multiselect-legacy.min.js and term-multiselect-legacy.min.js files to match

Install Widget Options

First step you need to install the Widget Options plugin (free) from the WordPress repository ( https://wordpress.org/plugins/widget-options/ ).  You do not need the full version, everything can be done using the free version of this plugin.

Open/Edit Widget to Show/Hide

Widget Options Tab

Now from the WordPress admin area, click on Appearance > Widgets to open the widgets configuration page.

Next open/expand the widget you want to configure the logic on.  You will notice a new section will appear on every widget, and should look like the screenshot to the left.

This new section will have multiple tabs at the top to select from, the only one we care about is the one that looks like a gear/cog/settings icon.  Click that icon and it should show additional tabs below it.

There will be multiple tabs shown, but the one we care about is the one labeled Logic

Configure Widget Logic

Widget Options Logic Tab

This is where you can add any custom PHP you wish, that will determine whether or not to show the widget.

Below I will give you some example code to use, but if you’re familiar with PHP, you can use any PHP code in this section to determine whether or not to show the widget.

The widget WILL show if value returned is TRUE

The widget WILL NOT show if the value returned is FALSE

Widget Logic Examples

Advanced Example

In the screenshot you will see some example code I am using to check against a custom field I have created, job_hide_widget.  This field is a simple/standard checkbox, that when saved to a listing will have a value of ZERO (or no value at all) if it was not checked, value of 1 if it was.

Let’s break down the code i’m using, here’s the first line:

$hide = get_custom_field('job_hide_widget', get_the_ID(), array( 'output_as' => 'value' ) );

Here we are using the get_custom_field function to obtain the value of a field.  Because we are using this to check logic, we have to pass two additional parameters.

The second parameter is the Listing ID, which can be obtained using the WordPress get_the_ID() function.  You can also pass null to have the get_custom_field function determine the listing ID for you.

The third parameter is an array of arguments to pass to the function.  These arguments are exactly the same as the parameters/arguments you can pass to shortcodes.  You will notice in this example I am using array( 'output_as' => 'value' ) … this is because we do NOT want the field editor to add HTML or other formatting to the returned value, so this tells the function to ONLY return the value.

note: in an upcoming release I will probably add a helper function specifically for this to make it easier and simpler to do this

We are then assigning the value returned to the $hide variable.  So in this specific example, because the checkbox is checked on the listing, $hide will have a value of 1

Here’s the last line:

return empty( $hide );

The last part is return empty( $hide ) … this is where we are returning to the widget options plugin a true or false value.  Because you must return true to show, or false to hide the widget is why i’m using empty( $hide ) to return.  The empty function will return true or false depending on the value passed.  If the value is an empty string, a zero, or false, it will return true.

So in this example, because $hide is 1 … empty( $hide ) returns FALSE because the value is not empty.

I know this was a complicated example if you don’t know PHP, so i’ll give you an easier much simpler one:

Simple Example

Instead of having a checkbox to Hide the widget, let’s instead use a meta key of job_show_widget instead.  If the listing has this checkbox checked, it will show the widget, if it does not, it will hide the widget.

Here’s the code we would use for that:

$show = get_custom_field('job_show_widget', null, array( 'output_as' => 'value' ) );
return $show;

Much simpler, right?  That’s because as mentioned above, when you return true in the widget logic, it will show the widget, when you return a false value it will hide it.

You could even make this one line by using just this:

return get_custom_field('job_show_widget', get_the_ID(), array( 'output_as' => 'value' ) );

Or even omit the return statement, as Widget Options plugin will automatically add the return if it does not find one in the logic:

get_custom_field('job_show_widget', get_the_ID(), array( 'output_as' => 'value' ) );

Go Futher

Now that you have some examples under your belt, you can take this even further to check for specific values, and so on.  This will require some basic PHP knowledge, and if you’re not familiar with PHP check out some quick beginner tutorials on YouTube to get you started!  Good luck!

WP Job Manager Field Editor Dynamic Taxonomy Child Dropdowns Demo

Dynamic Taxonomy Child Dropdowns

Advanced Field Configuration Tab

please note: this feature only works for hierarchal taxonomies (meaning only taxonomies you can set terms to have a “parent”).  This works for any taxonomy (custom or default) assigned to Job or Resume post types.

To enable this setting, edit the taxonomy field you want to use this new feature on.  As you can see in the screenshot on the left, there will now be a new setting you can enable “Child Dropdown“.

Enabling this setting will force the initial dropdown to ONLY show the top level category terms.  Once a term is selected from the dropdown, the associated child terms will be shown in a dynamically generated and shown dropdown.

By default, any child dropdowns shown, will inherit configuration from the main field (required, single/multiple, placeholder, etc)

Tutorial Video

Customizing Child Dropdowns

Dynamic Taxonomy Term Fields

To extend this feature even further, you can also completely customize how the dynamically shown child dropdown will be configured.

To customize the child dropdown, go to the taxonomy page (where you edit/add taxonomy terms), and you will now see a bunch of new fields that can be configured for each term.  This includes the type of dropdown (Single/Multiple), Max Selections (if using multiple), whether or not to require a selection, and a custom placeholder (details below).

If you already have existing taxonomies you want to modify, just click edit, and you will see all these new fields on the edit page.

Child Dropdown Settings

Below are each of the available settings for dynamically shown child dropdowns.  These settings can be found when editing a taxonomy term.  The settings apply to child terms of the term you configure them on.

Description

The main description field for the term (below where you select a parent), is what will be used for the description shown below the dynamically shown field (if one is set).

Child Dropdown

• inherit – This is the default setting.  The child dropdown will inherit settings from the main field configuration (required, single/multiple, placeholder)
• single – Force single select dropdown for all child terms, ignoring whether or not main field is single/multiple (visitor will only be able to select one option)
• multiple – Force multiple select dropdown for all child terms, ignoring whether or not main field is single/multiple

Max Selections

If parent (main field) is a multiple select field type, or if you forced child dropdown to be multiple (settings above), you can customize the max selections that can be made specifically for this child dropdown.

Require Selection

• inherit – This is the default setting.  The child dropdown will inherit required setting from main field configuration.
• Required – Force require a selection when this child dropdown is shown (ignoring main field configuration)
• Not Required – Force do not require a selection when this child dropdown is shown (ignoring main field configuration)

Placeholder

Use this field to set your own custom placeholder to use for the child dropdown.  The placeholder is what you see when no selections have been made in the dropdown (ie “Please choose an option”).  If this value is not set, the placeholder from the main field configuration (or the default from main field) will be used.

Child Dropdown + Conditional Logic

This initial release of the dynamic child dropdowns should be fully compatible with the Conditional Logic features.

There was a lot of time and effort put into making sure that the new dynamic child dropdowns were fully compatible with the conditional logic feature.  With that said though, because of the unlimited possibilities when it comes to conditional logic, there may be specific conditional logic setups that might not work correctly with the new dynamic dropdown features.  Please make sure to test all conditional logic setups after setting up any dynamic child dropdowns, to make sure that they work correctly with your setup.  If you find any issues, please make sure to open a support ticket and let me know.

Child Dropdown Examples

Using the example settings from image above (included below as well), this is how it would look in the output:

WP Job Manager Field Editor Dynamic Taxonomy Child Dropdowns Demo

Dynamic Taxonomy Term Fields

Required Child Dropdown

This release also adds some new handling i’ve been working on for HTML5 required validation on Chosen fields.  If you’re wondering what that means, think about when you submit a form for a Chosen field without selecting something … it submits and then loads the page again, showing an error for the submit.  The HTML5 validation is when a notification is shown before the page is submitted (the “please enter a value”).

The problem with Chosen.JS and HTML5 required fields, is the way that Chosen.JS initializes itself .. what is does, is creates a dynamic element, and actually hides the original select element … so when you try to use HTML5 validation, it doesn’t work, because the select element is hidden.

The solution I came up with uses only CSS, and from all my tests in 4-5 of the most popular Job Manager themes, it works great.  As of this initial release, i’ve only implemented this on child dropdowns.  Reason being is to allow users to thoroughly test this before adding this feature to the normal/standard chosen dropdowns (non child ones).

This documentation is for Field Editor 1.8.0 or OLDER, please see new documentation for 1.8.1 or newer!

https://plugins.smyl.es/docs-kb/field-editor-conditional-shortcodes/

Full shortcode attributes and reference can be found here:
https://plugins.smyl.es/docs-kb/shortcodes/

Nesting Caveats (version 1.8.0 or older)

If you want to use shortcode conditionals, for the time being, there is one caveat that you need to be aware of.  You can not use the same shortcode nested inside of a conditional shortcode.  This has been fixed in version 1.8.1 or newer by adding additional shortcodes you can use, as demonstrated above. As an example, this will NOT work:

[custom_field key="job_location"]
[custom_field key="job_hours"]
[custom_field key="job_salary"]
This listings salary is [job_field key="job_salary"] annually.
[/custom_field]

The reason the above code WILL NOT WORK CORRECTLY is because WordPress parser can not parse shortcodes that are used as non-enclosing and enclosing shortcodes.  Basically this means that the parser will assume the “content” is everything below [custom_field key=”job_location”]  and above [/custom_field]  … instead of our intended everything below [custom_field key=”job_salary”]  and above [/custom_field]   … as you can assume, WordPress has no way to know which opening shortcode is supposed to go with the closing one.

Temporary Workaround

The temporary workaround for the caveat above, is to ONLY use one of the available shortcodes as your enclosing shortcode, and one for outputting field values.  Because [custom_field]  [job_field]  and [resume_field]  all work exactly the same, this is fairly easy to deal with for the time being.  My suggestion is to use the [custom_field] shortcode for any enclosing shortcodes, and use [job_field] or [resume_field] for value outputs.  To show you what I mean, here is a WORKING revision on the code from above (that does not work):

[job_field key="job_location"]
[job_field key="job_hours"]
[custom_field key="job_salary"]
This listings salary is [job_field key="job_salary"] annually.
[/custom_field]

Notice how we no longer are mixing open/closing shortcodes, and non-closing shortcodes.  In the example above I decided to use the [custom_field] shortcode for shortcode conditionals, and [job_field] for outputting field values.  If you’re using shortcodes in say, a widget, you will only need to do this if you are outputting multiple fields in the same widget, as each widget is parsed individually for shortcodes.

THIS is not an issue in 1.8.1 or newer, please upgrade to the latest release and follow the updated documentation page:

https://plugins.smyl.es/docs-kb/field-editor-conditional-shortcodes/

What are conditionals?

Conditionals allow you to specify when you want some custom content to be output, based on the value of a field on a listing.  The best way to explain this, is with examples, so let’s dive right into it.  Here’s a basic example of using the conditional shortcodes:

[custom_field key="job_salary"]
This listings salary is [job_field key="job_salary"] annually.
[/custom_field]

As you can see above, instead of using a standard [custom_field key=”job_salary”]  you can now add a closing shortcode ([/custom_field] ) which allows you to specify custom content (or other shortcodes), before the closing shortcode, which will only be output, if that field has a value.

In the example above, if job_salary had a value of $40,000, this would be the output on the listing:

The listing salary is $40,000 annually.

Conditional [else]

In additional to the standard conditional shortcode, you can also nest an [else]  shortcode inside of the shortcode content, to specify content to output if the field does not have a value.  Using the example above, let’s add an [else] shortcode to it:

[custom_field key="job_salary"]
This listings salary is [job_field key="job_salary"] annually.
[else]
This listing does not provide a salary.
[/custom_field]

In the example above, we have added an [else] shortcode, which will output any content (and/or shortcodes) below the [else] shortcode, and above the closing shortcode [/custom_field] , when the field does not have a value (or the original logic evaluates to false.  See below for more details).

Conditional Value Checking

You can also fine tune the shortcodes even more, using conditional value checking.  Conditional value checking allows you to add any of the available value checks below, to the shortcode attributes:

• if_contains  – single string non-taxonomy value fields – check anywhere in the string value of the field, if it contains the passed value
• if_equals  – single string non-taxonomy value fields – check if the string value of the field, equals exactly the value passed
• has_value  – array/multiple/taxonomy value fields – check if any of the field values, equals exactly the value passed
• has_value_containing  – array/multiple/taxonomy value fields – check if any of the field values, contains any part of the passed value

So let’s get right into an example for the attributes above.  Let’s say you have a field with a meta key of job_start_time, and you want to output specific text if that value contains AM or PM:

[custom_field key="job_start_time" if_contains="AM"]
This is an early morning position, that starts at [job_field key="job_start_time"]
[/custom_field]

This would check the value of the job_start_time field, and if it contains AM in the value, it would output whatever is inside the shortcode content (before closing bracket).  To keep the examples simple, I removed the [else]  shortcode, but that can be used anywhere in the conditional shortcodes logic.  If the value of that field does not contain AM (exactly as you entered it), nothing will be output.

Array/Multiple/Taxonomy Value Fields

These type of fields would be something like, multiselect fields (including taxonomies), or multiple file upload fields.  If the field type can save multiple values you must use has_value  or has_value_containing  … which work exactly the same as if_contains  and if_equals … but for multiple value fields.  Example using job_category when set to allow multiple categories:

[custom_field key="job_category" has_value="Restaurant"]
This is a Restaurant listing because the Restaurant category was ONE of the selected categories!
[/custom_field]

Something to keep in mind though … if the user selected Restaurant AND Cafe under categories, the above will output specifically because Restaurant was selected .. even if other categories were selected as well!

Taxonomy Fields

If the field you are outputting a value from is a taxonomy field, you MUST use the has_value or has_value_containing attribute (instead of if_equals or if_contains), even if it’s not a multiselect or multi-value taxonomy field.  This is because Taxonomy fields are returned as an array (even if they are single value/selection), and as such, you must use the attributes for array/multi fields even if they are single dropdown taxonomy select fields.

Negating Shortcodes Conditions

You can also negate conditional value checking, by adding the NOT attribute (without a value) inside the opening shortcode.  This basically will do the opposite of whatever value checking attribute you decide to use.  So using our example above, if I wanted to output something (without using an [else] statement), when job_start_time does NOT contain “AM”:

[custom_field key="job_start_time" NOT if_contains="AM"]
This IS NOT an early morning position, it starts at [job_field key="job_start_time"]
[/custom_field]

Using a negated shortcode condition would be used in situations where you don’t want to output anything when it equates to true, but do want to output something with it does NOT equate to true.  This would be exactly the same as doing this:

[custom_field key="job_start_time" if_contains="AM"]
[else]
This is an early morning position, that starts at [job_field key="job_start_time"]
[/custom_field]

Case Sensitive Values

There may be situations where you are unsure if the user entered AM or am (uppercase or lowercase, or anything in between), and by default the values you enter ARE NOT CASE SENSITIVE … if you want them to be case sensitive, you can also pass the case_sensitive attribute with a value of true and it will check values, only matching if the value is exactly the same (case wise):

[custom_field key="yes_field" if_equals="YES" case_sensitive="true"]
This will only be output when the value equals YES exactly!  If the value were Yes, yes, yEs, yeS, etc you would not see this.
[/custom_field]

Video Tutorial

The conditional shortcodes starts around 8 minutes in, on the video below:

By default, admin only fields can NOT be selected anymore in the conditional logic configuration area.  This can easily be changed by using a filter.

Enable/Expose ALL Admin Only Fields

WARNING: this exposes all admin only field values on the frontend of your website in a JavaScript object. It is STRONGLY recommended that you ALSO use the filter below this one to ONLY output specific admin only field values.  I assume NO LIABILITY if you do not heed this warning!

add_filter( 'field_editor_conditional_logic_enable_admin_logic_fields', '__return_true' );

The above code added to your child theme’s functions.php file, or using the Code Snippets plugin, will now allow you to select from any of your configured Admin Only fields, for use in conditional logic checks.

Customize Specific Admin Only Fields to Expose/Enable

It is STRONGLY recommended that you add this filter as well, to specify ONLY what meta keys of admin only fields you want to be used for conditional logic, as to only output those values on the frontend javascript object storage:

There are two filters available for this.  One is for Jobs/Listings:

field_editor_conditional_logic_custom_value_job_admin_fields

The other is for Resumes:

field_editor_conditional_logic_custom_value_resume_admin_fields

Here’s an example using the job/listing filter:

add_filter( 'field_editor_conditional_logic_custom_value_job_admin_fields', 'smyles_logic_admin_only_job_meta_keys' );

function smyles_logic_admin_only_job_meta_keys( $admin_only ){
	$admin_only = array( 'job_admin_only' );
	return $admin_only;
}

As you can see in the example above, I am ONLY returning the job_admin_only  meta key through the filter, specifying I only want that one to be used for logic and to be output on the frontend javascript object storage (the value of that field for the listing).

Multiple meta keys can be specified by simply adding another one in the array:

$admin_only = array( 'job_admin_only', 'job_admin_only_2' );

The values passed to the example function above $admin_only , is an array of all the admin only fields on your site.  By simply redefining that array and returning our new one, you are instructing my plugin to ONLY allow that field for use.

Specifying Default Values

You can also specify a default value you want to be used whenever a new listing is being created, or when an existing listing is being edited, that does not have a value saved to the listing, for that field.  To do this, we just create a nested array on the meta key we want to set the default value for:

$admin_only = array( 'job_admin_only' => array( 'default' => 'VALUE' ) );

This will result in any logic you have setup on that field, to use that VALUE  as default.  For example, a user is creating a new listing, and you have logic configured to show job_salary  when job_admin_only  is VALUE  … when the page loads, the job_salary  field will be showing, because you have set VALUE as a default value for that field.  If you then edit that listing as an administrator in the admin backend and change that value to something else … when the frontend user goes to edit the listing again, they will no longer see the job_salary  field.

Here’s a full example with all the features described above:

add_filter( 'field_editor_conditional_logic_enable_admin_logic_fields', '__return_true' );
add_filter( 'field_editor_conditional_logic_custom_value_job_admin_fields', 'smyles_logic_admin_only_job_meta_keys' );

function smyles_logic_admin_only_job_meta_keys( $admin_only ){

	$admin_only = array(
		'job_admin_only' => array(
			'default' => 'yes'
		),
		'job_admin_only_2' => array(
			'default' => 'no'
		),
	);

	return $admin_only;
}

Documentation for Conditional Shortcodes in version 1.7.0 through 1.8.0, can be found here:
https://plugins.smyl.es/docs-kb/field-editor-conditional-shortcodes-1-7-0-1-8-0/

Full shortcode attributes and reference can be found here:
https://plugins.smyl.es/docs-kb/shortcodes/

Conditional Shortcodes

These are the 3 new shortcodes included with version 1.8.1 of the Field Editor addon:

if_custom_field  if_job_field  if_resume_field

Conditional Shortcodes Attributes

• equals  – value to check against value on listing
  single value fields – checks if the the value from the listing, matches exactly the value that was passed
  multiple value fields/taxonomies – checks if the ONLY value selected equals the value passed.  In regards to multiple value fields, think of this as “ONLY equals“
• contains  – value to check for anywhere in the value on the listing
  single value fields – checks if anywhere in the value on the listing, the value passed exists
  multiple value fields/taxonomies – checks if ANY of the values match the value passed (this will be most common one used for taxonomies)

Both attributes/arguments are optional, and if neither are passed, any value (other than an empty one) on the listing will result in the check returning true

What are conditionals?

Conditionals allow you to specify when you want some custom content to be output, based on the value of a field on a listing.  The best way to explain this, is with examples, so let’s dive right into it.  Here’s a basic example of using the conditional shortcodes:

[if_custom_field key="job_salary"]
    This listings salary is [job_field key="job_salary"] annually.
[/custom_field]

As you can see above, we are using one of the new conditional shortcodes [if_custom_field key=”job_salary”]  , along with a closing shortcode ([/if_custom_field] ) which allows you to specify custom content (or other shortcodes), before the closing shortcode, which will only be output, if that field has a value.

In the example above, if job_salary  had a value of $40,000, this would be the output on the listing:

The listing salary is $40,000 annually.

Conditional [else]

In additional to the standard conditional shortcode, you can also nest an [else]  shortcode inside of the shortcode content, to specify content to output if the field does not have a value.  Using the example above, let’s add an [else] shortcode to it:

[if_custom_field key="job_salary"]
    This listings salary is [job_field key="job_salary"] annually.
[else]
    This listing does not provide a salary.
[/if_custom_field]

In the example above, we have added an [else] shortcode, which will output any content (and/or shortcodes) below the [else] shortcode, and above the closing shortcode [/custom_field] , when the field does not have a value (or the original logic evaluates to false.  See below for more details).

Conditional Value Checking

You can also fine tune the shortcodes even more, using conditional value checking.  Conditional value checking allows you to check for specific values using the arguments found above.

[if_custom_field key="job_start_time" contains="AM"]
    This is an early morning position, that starts at [job_field key="job_start_time"]
[/if_custom_field]

This would check the value of the job_start_time field, and if it contains AM in the value, it would output whatever is inside the shortcode content (before closing bracket).  To keep the examples simple, I removed the [else]  shortcode, but that can be used anywhere in the conditional shortcodes logic.  If the value of that field does not contain AM (exactly as you entered it), nothing will be output.

Array/Multiple/Taxonomy Value Fields

These type of fields would be something like, multiselect fields (including taxonomies), or multiple file upload fields.  If the field type can save multiple values you should make sure to choose the right value checking argument. Example using job_category when set to allow multiple categories:

[if_custom_field key="job_category" contains="Restaurant"]
    This is a Restaurant listing because the Restaurant category was ONE of the selected categories!
[/if_custom_field]

If the user selected Restaurant AND Cafe under categories, the above will output specifically because Restaurant was selected .. even if other categories were selected as well!

Using the equals shortcode on multiple value field types will ONLY result in being true (outputting value above [else]), if there is only one value and that value matches the passed value.  You can think of using equals with multiple value field types as meaning “ONLY equals“.

As example, if we instead used equals instead of contains like above:

[if_custom_field key="job_category" equals="Restaurant"]
    This is a Restaurant listing because the Restaurant category was ONE of the selected categories!
[/if_custom_field]

Nothing would output from the above shortcode … why?  Because both Restaurant AND Cafe were selected, and since you used equals .. technically it does not only equal Restaurant

Negating Shortcodes Conditions

You can also negate conditional value checking, by adding the NOT attribute (without a value) inside the opening shortcode.  This basically will do the opposite of whatever value checking attribute you decide to use.  So using our example above, if I wanted to output something (without using an [else] statement), when job_start_time does NOT contain “AM”:

[if_custom_field key="job_start_time" NOT contains="AM"]
    This IS NOT an early morning position, it starts at [job_field key="job_start_time"]
[/if_custom_field]

Using a negated shortcode condition would be used in situations where you don’t want to output anything when it equates to true, but do want to output something with it does NOT equate to true.  This would be exactly the same as doing this:

[if_custom_field key="job_start_time" contains="AM"]
[else]
    This is an early morning position, that starts at [job_field key="job_start_time"]
[/if_custom_field]

Case Sensitive Values

There may be situations where you are unsure if the user entered AM or am (uppercase or lowercase, or anything in between), and by default the values you enter ARE NOT CASE SENSITIVE … if you want them to be case sensitive, you can also pass the case_sensitive attribute with a value of true and it will check values, only matching if the value is exactly the same (case wise):

[if_custom_field key="yes_field" equals="YES" case_sensitive="true"]
    This will only be output when the value equals YES exactly! If the value were Yes, yes, yEs, yeS, etc you would not see this.
[/if_custom_field]

Nesting Caveats

If you want to use shortcode conditionals, there is one caveat that you need to be aware of.  You can not use the same shortcode nested inside of itself. As an example, this will NOT work:

[if_custom_field key="job_hours"]
    [if_custom_field key="job_salary"]
        This listings salary is [job_field key="job_salary"] annually.
    [/if_custom_field]
[/if_custom_field]

The reason the above code WILL NOT WORK CORRECTLY  … as you can assume, WordPress has no way to know which opening shortcode is supposed to go with the closing one.

Workaround

The workaround for the caveat above, is to use multiple conditional shortcodes as required (even if it’s not a job or resume).  That’s the reason for having the extra if_job_field and if_resume_field … all three of the if shortcodes do exactly the same thing, and call the same exact function, but because they are different, WordPress can parse the shortcodes when they are nested, so for instance, this would work:

[if_custom_field key="job_hours"]
    [if_job_field key="job_salary"]
        This listings salary is [job_field key="job_salary"] annually.
    [/if_job_field]
[/if_custom_field]

You can still use all the other standard shortcodes inside of the conditional shortcodes, the only issue is with using the SAME conditional shortcode, nested inside of itself.  Voila!

This documentation is only applicable for any of the FORM FIELD templates (found inside form-fields directory), all other template overrides will work like normal and you should follow the WP Job Manager Template Overrides documentation for that.

Template Files

Because WP Job Manager Field Editor adds many features to the existing field types included with WP Job Manager, as well as, numerous custom field types, if you want to customize these templates, you MUST use the template files from the wp-content/plugins/wp-job-manager-field-editor/templates/form-fields  directory to retain the enhancements and added features.  If you do not, features such as, max selected images, max selected categories, max image size, etc, will not work correctly if you use the default form field templates from the WP Job Manager templates directory.

So first, you will need to look in that directory, wp-content/plugins/wp-job-manager-field-editor/templates/form-fields, and see if the form field template file exists that you want to customize (if it does not, you can just follow the default WP Job Manager template overrides documentation).

Template Directory

Next you will need to create a new directory inside your CHILD THEME directory to store these template override files.   Just like in the documentation for WP Job Manager template override files, everything is exactly the same, except instead of using job_manager  as the directory, you MUST use field_editor  instead.  You can then create another directory inside field_editor  directory, named form-fields  (just like in WP Job Manager documentation).

Examples

So as an example, if you’re using the Jobify theme, and want to customize the multiselect field template file, you need to create two directories inside your jobify child theme:

/wp-content/themes/jobify-child/field_editor/
/wp-content/themes/jobify-child/field_editor/form-fields

You would then copy the /wp-content/plugins/wp-job-manager-field-editor/templates/form-fields/multiselect-field.php  file to the form-fields directory we just created, ultimately resulting in this file:

/wp-content/themes/jobify-child/field_editor/form-fields/multiselect-field.php

You can then edit that file, make any modifications you would like, and that template file will be used instead of the default WP Job Manager Field Editor one.

This is exactly the same as the WP Job Manager Template Overrides, with the exception of using field_editor as the root directory in your child theme’s directory, instead of job_manager.

Why not just use job_manager structure?

The reason I decided to take priority of field editor templates over the default WP Job Manager form field templates, is as explained above, because WP Job Manager Field Editor adds many features to existing form fields, and as such, to prevent errors on sites, features from not working, etc, I configured it so you must use the field_editor directory to specify that you are in fact, using the field editor template files.  This was also done to prevent backwards compatibility issues with older, out-dated template files that may still exist on client sites.