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.

Turn this:

Into this:

Preface

I created this guide strictly for references purposes to get you started in the right direction.  This is not something that is supported, and you should contact your theme developers for any specific customizations you want.  Customizations is not something included in the scope of any of my plugins, and as such, I can not provide support to customize themes.  Again this tutorial is for informational purposes only, you will still probably have to tweak these settings to work correctly with your theme, but at least you have somewhere to start.

Creating Two Columns

To create the two columns in this tutorial I will be using CSS width and float.  This should work with almost every theme, but I can not guarantee it, as all themes are different.

fieldset[class^="fieldset-"] {
    float: left;
    width: 48%;
}

In the CSS above, we’re using float to make all fieldset HTML elements float left (so they will pull left), with a width of 48% (so we can use the remaining 4% for space between them in the middle).  The CSS attribute selector used will apply these styles to ALL fieldset HTML elements that have a class that starts with a fieldset- … this will essential select fieldset-job_title fieldset-some_meta_key  .. etc

As you can see on the right, using developer tools you can set that all fields have a class that starts with fieldset-

Adding space between fields

We now want to add space between the two fields so they are not right on top of each other.  To do this we will use the same type of CSS selector as above, with the exception this time of using the nth-child selector to only select the ODD fields (meaning first, third, fifth, and so on).

fieldset[class^="fieldset-"]:nth-child(odd) {
    margin-right: 4%;
}

As you can see above we’re setting the right margin to 4%, which is why we used a width of 48% above.

This should result in output similar to the image on the left.  You will probably have to tweak and play around with the CSS to get all fields to look correctly, but this should get you started in the right direction.

Customizing Single Fields

You may want to customize specific fields to show full width, or with custom CSS.  To do so it’s very easy as each field will have a class associated with the field’s meta key.  For this example, let’s say we want the Listing Description field to be full (100% width) while leaving all the other fields to be 50%.

.fieldset-job_description {
    width: 100%;
}

As you can see, we just use a CSS class selector with .fieldset-METAKEY  … replacing METAKEY with the meta key we want to modify, in the example above it would be job_description .

Voila! Profit!

Please note: support will not be provided for this tutorial as this tutorial covers customizations which is outside the scope of any of my plugins.  This tutorial is for informational and educational purposes only.

All you need to do is go to Edit the field you want to duplicate, and then change the meta key to the meta key you want to duplicate the field to.  Voila!  It was that easy!

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!

Overview

The open source jQuery plugin used for the phone field type is called International Telephone Input, and you can find all the information you would need about it (including details on the available configuration and options) on GitHub:

https://github.com/Bluefieldscom/intl-tel-input

As the latest version from above is newer than the current version included with the field editor, please see this URL for documentation on the version included with the field editor:

https://github.com/jackocnr/intl-tel-input/tree/8a2364bc0459fce934d7cf04a82823db63e7944b

In order to modify any of the default options you will need to use a WordPress Filter that is placed in your theme’s functions.php  file.  The filter you will need to use to override the default arguments is:

job_manager_field_editor_phone_args

Below you will see the code directly from the plugin that shows the currently supported options/configurations:

$phone_args = apply_filters( 'job_manager_field_editor_phone_args', array(
	'allowExtensions'    => false,
	'autoFormat'         => true,
	'autoHideDialCode'   => true,
	'autoPlaceholder'    => true,
	'defaultCountry'     => '',
	'ipinfoToken'        => '',
	'nationalMode'       => false,
	'numberType'         => 'MOBILE',
	'preferredCountries' => array('us', 'gb'),
	'utilsScript'        => WPJM_FIELD_EDITOR_PLUGIN_URL . '/assets/js/phoneutils.min.js'
	)
);

You should never need to modify the utilsScript value (unless you really know what you’re doing).  Make sure to read the GitHub page for specific details on the values before changing them.

Example Configuration

Note: any options that take country codes should be ISO 3166-1 alpha-2 codes

For this example we will be changing the phone field type to automatically detect and select the user’s country based on their IP.  If the location can not be determined by IP, we will have it default to France.  We will also set the countries to show at the top of the dropdown list to France, and Germany.

If you read the documentation from the GitHub page, you will see that if we set the value of defaultCountry to auto it will automatically attempt to detect the user’s location based on their IP.  That is why in the example screenshot above you can see the country shows USA, but the other countries at the top are France and Germany.  This is because my IP address is located in the USA and it automatically set it to USA.

To set the countries at the top of the dropdown list, we will use preferredCountries

This would be the final code you would need to add to your functions.php file, I will go over each part below.

add_filter( 'job_manager_field_editor_phone_args', 'my_custom_phone_args' );

function my_custom_phone_args( $args ){

	$args['preferredCountries'] = array( 'fr', 'de' );
	$args['defaultCountry'] = 'auto';

	return $args;
}

 Example Breakdown

So the first code we need to add is the add_filter  which tells WordPress to run our custom function so we are able to modify the values:

add_filter( 'job_manager_field_editor_phone_args', 'my_custom_phone_args' );

The code above adds a hook to the field editor filter, and then runs my_custom_phone_args  function whenever the filter is called from the plugin.

The next code added is the function that is called:

function my_custom_phone_args( $args ){

	$args['preferredCountries'] = array( 'fr', 'de' );
	$args['defaultCountry'] = 'auto';

	return $args;
}

As you can see in the function above, $args  is passed to the function which includes all of the default arguments.  Using standard PHP we can modify those values as needed, and as you see at the bottom, then return the $args  back to the hook.  You MUST return the $args  otherwise you will have issues.  Using the country codes obtained from the ISO 3166-1 alpha-2 codes, the possibilities are endless!

This same method can be used to override any of the other default configuration values, but PLEASE make sure to read the documentation on the GitHub page to make sure you use the right values.

If you change any of the boolean values (true or false), do not place them in quotes, they should be just like the values you see above in the default configuration.

Change Resume Candidate Skills Field

Head on over to the Resume fields section and locate the resume_skills meta key in the list table (you must have Resume Skills enabled in the WP Job Manager Resume Settings), and click on the Edit link.

This will bring up the configuration for the Resume Skills field, the key items you want to update will be the Type and Taxonomy.

Type – click on the dropdown and select Taxonomy Multi-Select Dropdown

Taxonomy – enter in resume_skill (you must enter resume_skill exactly as you can see in the screenshot)

Candidate Skills Frontend Demo

Click save, head on over to your site and you will see that now users can only select from items you added to the Candidate Skills section!

Profit!