• 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]

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).

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.

Full Tutorial

WP Job Manager Field Editor now has conditional fields available, current in beta phase while testing is completed and bugs are reported.  Below you will find some information about how to use Conditional Fields.

Beta Key Points

• If you configure a group to Show fields, they will be automagically hidden by default (unless logic results in true, then they will be shown)
• Conditional fields are currently NOT supported in admin area (this requires customized code for admin area, which is still being worked on)
• Checkbox values are either 1 or 0 (one or zero), 1 means checked, 0 means unchecked (for entering in logic)
• Taxonomy field value are based on the TERM/TAG ID .. not the slug, or the wording.  When editing a specific taxonomy term, look at the URL and you will see tag_ID=XXX
  In an upcoming release, the value field when setting up logic will automatically change based on the selected field, allowing you to select from available options
• Taxonomy field comparison with IS or IS NOT for taxonomy multiselects will check if ONLY that field is (or is not) selected.  Use contains to check IF a value is selected (allowing other selections as well)
• This feature is in beta phase, and as such, please make sure to report any issues or problems you have … BUT FIRST read ALL documentation to make sure it’s not covered already.  The majority of the time the problem is user error and configuration, not a problem with the plugin.  Make sure to check the Developer Console for javascript errors when having problems.
• You should NOT hide any fields required by core WP Job Manager (job_title or candidate_name) as if the listing is submitted without those fields, there will be errors!  Basically if you are unable to disable the field, you should NOT be hiding it or setting up logic that could result in that field not being set when the listing is submitted!
• You should always test the logic yourself, don’t just assume it works, makes sure you test 100% before pushing live to your site

Logic

WP Job Manager Field Editor Conditional Logic Disable Fields

The setup I decided to go with for handling conditional fields logic, was based on a groups with logic applied to those groups.  When first setting up a new conditional logic, you will have to create a group.  In this group, you will define the fields that you want any of the logic configured in that group, to be applied to.  The currently available group types (could also be called “group action”), is show, hide, disable, or enable.

This means that if any of the logic you configure in the group, returns true, then the type configured in the group, will be applied to all fields set in the group configuration.

As you can see in the example above, the group configuration is set to disable the company_website, company_tagline, and company_logo fields.  This means that if any of the logic configured for that group returns true, then all those fields will be disabled.  In the example above, the only logic configured is when company_name is blank … this means that normally when a new listing is submitted … those fields will already be disabled, and will only be enabled when that logic no longer returns true.

Logic Conditions

WP Job Manager Field Editor Conditional Logic Conditions

When creating logic for a group, you will be able to select the meta key to compare/check (soon to include other features, like user capability, role, etc), and then a logic condition to use for determining if that logic should be considered TRUE which will then apply the configuration set in the group on the fields, set in the group.  As you can see above, there are currently 8 available conditions, which can be used for checking the logic of the selected metakey.

The value to use the comparison against is on the right next to the dropdown for selecting the comparison.  Leaving this field blank will result is checking if that field does not have a value (or is empty).

All comparisons are done case-insensitive (meaning case does not matter), which can be changed via  filter if you need case sensitivity.

• IS – exact value comparison/check DOES match entered value (if a taxonomy field, IS means “IS ONLY”, use contains for “is selected” for taxonomy multiselect)
• IS NOT – exact value comparison/check does NOT match entered value (if taxonomy field, IS NOT means “IS NOT ONLY”)
• IS GREATER THAN – check if field value is greater ( > ) than entered value.  If field is a multiselect, can be used to define selections greater than
• IS LESS THAN – check if field value is less ( < ) than entered value.  If field is a multiselect, can be used to define selections less than
• STARTS WITH – check to see if value starts with entered value
• ENDS WITH – check to see if value ends with entered value
• CONTAINS – check to see if value contains entered value.  This should be used for multiselect (and taxonomy multiselect) fields to check if a value has been selected.
• DOES NOT CONTAIN – check to see if value does NOT contain entered value.  This should be used for multiselect fields to check if a value has NOT been selected.

Field Type Values

• Checkbox – value of 1 means “checked”, value of 0 means “unchecked”
• Taxonomy – you MUST use the taxonomy term/tag ID, to find the taxonomy term ID, go to the taxonomy page, and click Edit on the taxonomy term you want to get the ID for.  In the URL bar you will see something similar to this:

  /wp-admin/term.php?taxonomy=resume_skill&tag_ID=23&post_type=resume

  The taxonomy term ID (called tag_ID in URL) will be located right after tag_ID.  In the example above, the term ID is 23

AND Logic

WP Job Manager Field Editor Conditional Fields AND Logic

Logic “sections” as they are called, can include an unlimited number of AND logic configurations, simply by clicking the blue button in the bottom right corner of the section box.  This will add another line below the initial IF row, where you can select additional AND logic.

In the example above, that logic section will only apply the configuration set in the group configuration, IF the field company_name IS NOT equal to “smyles” AND job_title has an empty value, otherwise, nothing will be applied … unless you add additional OR logic, explained below:

OR Logic

WP Job Manager Field Editor Conditional Logic Disable Fields OR AND Logic

The logic handling has multiple options, allowing you to create very intricate and customized logic configurations, called “sections” for creating OR logic.  As you can see in the example above, we now have an additional logic section, separated by OR (added by clicking Add Conditional Section, or clicking the plus icon in bottom right corner).

Along with adding unlimited number of AND logic per section, you can also add an unlimited number of OR logic configurations.  This allows you to apply the configuration on the group, whenever ANY of the sections evaluate to true.

In the example above, the company_website and company_tagline field will be disabled, whenever company_name does NOT equal “smyles”  … OR … whenever company_name DOES equal “smyles” and job_location field CONTAINS “Orlando”.

PLEASE watch the entire Conditional Logic Tutorial Video for full details

Because WP Job Manager Field Editor does not include any styles (which 99% of the time causes problems), the plugin relies on your theme or adding custom styles to get everything to appear exactly how you would want it to.  Luckily I took this into consideration when adding this new features and as such there are standard wrapper and field divs that you can use to create your own CSS styles ( will probably add this as a feature in future release ).

Top/Bottom of Job Listing

Each custom field you set to automatically output on the job/resume listing will be wrapped in a <div>  with 1 class and 1 ID.

The value from the custom field will be inside another <div>  with 1 class and 1 ID.  The syntax used for the <div>  you can see below, the actual output will vary based on the field’s meta key, so using the syntax below FIELD_META_KEY  will be whatever that field’s meta key is.

Wrapper DIV:

<div id="jmfe-wrap-FIELD_META_KEY" class="jmfe-custom-field-wrap">

Field Value DIV:

<div id="jmfe-custom-FIELD_META_KEY" class="jmfe-custom-field">

As an example, if you were to set a custom field with a meta key of job_salary  to output at the top of the job listing, this is the HTML the plugin will automatically generate:

<div id="jmfe-wrap-job_salary" class="jmfe-custom-field-wrap">
    <strong>Job Salary:</strong>
    <div id="jmfe-custom-job_salary" class="jmfe-custom-field">
        $99,000
    </div>
</div>

You can also specify your own custom classes to add to the field value’s <div>  which I will explain further below.

The <strong>Job Salary:</strong>  is added only when Show Label is checked in the field configuration.

Meta Start/End Output

If you decide to pick to automatically output at meta start or meta end the ID and classes are exactly the same above except that instead of a <div>  for the wrapper it will be an <li>  wrapper.  Below is an example of the automatically generated HTML for the same field from above, except this example would be either at meta start or meta end:

<li id="jmfe-wrap-job_salary" class="jmfe-custom-field-wrap">
    <strong>Job Salary:</strong>
    <div id="jmfe-custom-job_salary" class="jmfe-custom-field">
        $99,000
    </div>
</li>

This is because the meta locations are inside of the <ul class=”meta”>  wrapper and in order to show correctly they must be added as <li>  items.

This will not set the listing as a “Featured Listing” this will only set the “Featured Image” on the listing.

Featured image for a listing is commonly used by themes and other plugins as the “image” of the post/listing.  Specifically the Jobify theme uses the featured image as the image for displaying any featured jobs on the homepage.

To do this is very easy, all you need to do is create a new field, and use the meta key featured_image  …. and that’s it!

Make sure to set the field as a file upload field, with the meta key featured_image, and that’s it!

Profit!