Matador Jobs Lite

Descrição

Connect your Bullhorn Account with your WordPress site and display your valuable jobs on your new self-hosted job board. Matador makes this as easy as it sounds, and lets you seamlessly integrate a powerful job board–a major marketing tool for your business–directly into your WordPress site. Everything that is great about WordPress is extended to Matador: great out-of-the-box SEO, easy templating/theming, endless customization options, and more. Matador goes further by listing your jobs with incredible job-specific SEO customization (optimized for Google Jobs Search), and more.

Use Matador’s powerful settings to connect our “Apply Now” button for jobs to a page that will collect applications, or look into purchasing Matador Jobs Pro to accept applications from Matador and see them turned into candidates submitted to jobs directly in your Bullhorn Account!

3.9.4

• Bugfix: The uploaded files metabox will now display again after going missing on Application admin views with 3.9.0.
• Bugfix: Fixed an issue encountered only by logged in admin users when accessing cached Matador forms. Cross-site request forgery protections were not being properly refreshed on cached pages for admin users. While this did not impact most customer users, it made testing staging/development sites frustrating for site admins and developers.
• Bugfix: (Bullhorn Integration) Fixed an issue causing the job_general_location to still not save correctly. 2nd times the charm here?
• Bugfix: (Bullhorn Integration) Fixed an issue during import causing the “is hybrid job” flag to not be saved.
• Bugfix: (Bullhorn Integration) Fixed an issue during import causing the “is remote job” flag to also be saved when a job is a hybrid job.

3.9.3

• Bugfix: Fixed issue with the reset button in default search, previously the reset button was unable to clear the form and reset the search query params in some circumstances.
• Bugfix: (Bullhorn) Fixed an issue where a Bullhorn job import for a job without a city/locality and a state/province would create a “job general location” with only a comma. Now, a missing city and state will result in an empty/not set “job general location.”
• Bugfix: Fixed issue allowing servers running PHP 7.4 to PHP 8.0.x to initialize Matador. Please upgrade to PHP 8.1, the minimum supported version of PHP for the plugin.

3.9.2

• Bugfix: Fixed issue causing admin javascript to fail to load, impacting the use of Matador Jobs settings screens when the WP_DEBUG or WP_SCRIPT_DEBUG is true or WordPress environment is set to DEVELOPMENT.
• Bugfix: Fixed issue with readme.txt file formatting that caused information about the plugin to not load properly when displayed on WordPress.org plugin repository and in the WordPress plugins admin screen.

3.9.1

• Unaddressed Known Issue: Matador Jobs 3.9.0 and 3.9.1 have an issue causing admin javascript to fail to load, impacting the use of Matador Jobs settings screens when the WP_DEBUG or WP_SCRIPT_DEBUG is true, or WordPress environment is set to DEVELOPMENT. This will be addressed in 3.9.2 ASAP.
• Bugfix: Fixed issue causing the packaging of Matador Jobs Lite to be incorrect, creating issues for our Lite users.

3.9.0

Key New Features

Matador Jobs Editor Blocks

We finally are confident in our WordPress Block Editor Blocks, and release them for our users to build robust front-end displays! Our editor blocks have 100% parity to our old shortcodes, and in fact add new features to customize display. Included blocks are:

• Jobs
• Jobs Filters
• Jobs Search
• Application
• Application Link
• Job Description
• Job Field
• Job Relative Age
• Job Link

See our guide to building block-based Matador layouts on our docs website ().

Application Screening

Application Screening, code-named “Traffic Lights”, gives users a method to control whether an application is synced to the external ATS. When enabled, the Application Screening feature will hold an application until a recruiter reviews (screens) it and performs an action. The recruiter will receive an email and/or notification on messaging apps (when Slack, etc, services are enabled) with a summary of the application data. The notification (and screens in the WordPress admin) will include action links that give them the recruiter the option to “reject”, “add”, or “apply”.

• “Reject” will remove the application data from the site and never submit it to your ATS system.
• “Add” will create a new person or candidate record in your ATS, but not submit that candidate for associated role. This allows recruiters to build a database of candidates even when the candidate may be unfit for the applied role.
• “Apply” will create a new person or candidate record in your ATS and then link the record as a job submission. This option may not appear for candidates who submit information on the general application form.

Application Screening will be powerful for users who are experiencing high volumes of unqualified candidates and/or spam applications. It is also useful for users who wish to more finely manage their ATS database.

Enhanced Logging

Matador Jobs 3.9.0 completely overhauls the event logging. Logs are an incredibly useful tool for site admins and developers alike to monitor how Matador is functioning. Since our initial release, new log entries have been added as Matador has grown in complexity and new quirks have been discovered, and this means logs were getting extremely detailed and long. Some sites were creating log files so huge that they were impacting site storage limits. While this information helps our users–and us, when debugging issues–understand what is going on, some log items are not necessary when a site and external connection is deemed operating effectively. This overhaul cleans up some legacy logging code, making it more efficient, and it also gives users granular control over what is logged so only the information a site admin needs is taking up space.

All logged items are now assigned a “Severity” by the developers. Severity are levels of importance, and are, least important to most important, are:

• Note, to log items which are extremely detailed pieces of information for debugging and validating function.
• Notice, to log items that modify or impact behavior in a way that is determined by settings or user filters. This type of log is helpful for us to discover the cause of “unexpected” behavior being the result of forgotten customizations or misunderstood settings values.
• Warning, to log items that imply something unexpected occurred, usually due to malformed external data or connection issues, but that does not affect Matador’s ability to run. For example
• Error, to log items that are errors that impact Matador’s ability to complete a task, and that interrupts Matador’s operation. Examples could include disconnections from external integrations or bad application data. These can trigger admin email alerts as well.
• Critical, to log items that Matador cannot recover from. These are usually unexpected errors and often a result of misuse of Developer Filters or issues with external connections that Matador developers have not written code to handle.
• Info, to log items that are important to the user for purely informational purposes. These always log. These can be confirmation of completed syncs, applications received, and more.

Along with this enhanced logging functionality, come the following highlights:

• Users can set a setting or filter to choose which level of severity are written to the logs. “Info” items will always be logged. Default is “Warning”.
• Added filter matador_activity_log_verbose which prints associated array data or object data to the logfile in addition to the log entry. This will create an extremely verbose, detailed log and should only be enabled during developer debugging.
• Enhancement: Four new constants are now supported related to logging. Defining these in a wp-config.php file will give a site developer power to override and hide the associated user settings:
• • MATADOR_LOGGING_ENABLED allows developers to turn on Matador Activity Logging.x
• • MATADOR_LOGGING_DAYS allows developers to define the number of days of logs to keep and removes the setting.
• • MATADOR_LOGGING_SEVERITY allows developers to define the logging severity level and removes the setting.
• • MATADOR_LOGGING_VERBOSE allows developers to configure whether arrays of metadata related to the action spawning the log entry should be printed into the logs.

Enhancements & Bugfixes

Jobs

• “Sync” job button is added to the Block Editor view of the Job Posting to ensure feature parity with the older Classic Editor.
• A Job Archive will now only be available via the front-end UI if the setting for an archive is turned on.
• Optimized database calls around the get job by ID function for Bullhorn. Four database calls are now optimized down to two.
• Fixed an issue where the jobs shortcode would not accept values from the jobs_per_page attribute. This is actually a change to support a long-time error in documentation, as docs described jobs_per_page while jobs_to_show was the intended attribute name.
• Fixed two issues and improved one behavior related to The Template_Support::the_job_meta() function. First, it will return an empty string instead of false when failing to find a post meta value for the field. This brings it in line with the behavior of other conditionals and in parity with its documentation. Further, the function was calling esc_html() on data, and some data was stored as an object, which was resulting in a fatal error. This method now detects if the retrieved metadata is an object or array and avoids the error. Finally, if the retrieved data is an object and has a name property, then the is returned as the meta value. To get the full object, use get_post_meta() instead.
• Fixed an issue causing Matador Jobs Lite sites to not have access to Salary related settings from the 3.8.x family of patches. These settings have been extended to Lite users.
• REST API is enabled for Matador Jobs Job Postings.

Taxonomies (Locations, Categories, Etc)

• A new “auto suggest” input type for taxonomy search is now available: text input with datalist. This input type uses existing taxonomy terms to autosuggest values to users as they fill in the input. By default, this feature is not enabled to maintain backward compatibility with existing CSS on sites which may rely on taxonomy search fields being elements. To enable this new field on a site-wide basis use the matador_search_form_args filter to set taxonomy_type => 'datalist'. Alternatively, the datalist field can be enabled in the Matador Search Editor Block, the matador_search shortcode by passing taxonomy_type=datalist, or in the matador_search() template function by setting taxonomy_type => 'datalist' in the arguments passed in.
• Job Taxonomy Editor Block, Shortcode, and Template Function now supports the “order” argument, which allows the user to dictate whether results are sorted ascending or descending. The default behavior is to sort ascending except when the ‘orderby’ argument is set to ‘count’, in which case Matador will default the ordering to descending (highest count to lowest count).
• The Location taxonomy term “Hybrid” will be added, like we add a “Remote” term, for jobs which rules that determine it is a part-time in office, part-time work-from-home role. A CSS class is also added to jobs which are remote or hybrid, which can be used by developers to highlight these roles. For backward compatibility, the CSS class is not used to change existing sites’ appearance.
• Taxonomy (eg: job category) terms (eg: “Accounting”) will now include additional data from the remote source, including “remote category ID” when a term is imported from an external ATS source.
• The WordPress theme will now use a Matador Jobs archive template for the taxonomy pages if a taxonomy-specific archive is not found, simplifying theming work for Matador Jobs.
• Job Taxonomy Archives will now have the five default feeds disabled by default. Enable all by unhooking the action remove_action( 'pre_get_posts', [ 'matador\Job_Taxonomies', 'disable_feed' ], 10 ); or enable certain default feeds by modifying the list of disabled feeds with filter matador_taxonomies_disabled_feeds.
• Added argument to matador_import_meta_to_taxonomy_value filter with full job object, to offer users even more control in determining what the taxonomy term is saved (or if a taxonomy term is set at all).
• REST API is enabled for Matador Jobs Job Taxonomies.

Submissions (Applications)

• Added a Country field (drop-down) to the Matador Application Form. When possible, the list of countries are sourced from the connected ATS.
• Added a unique ID hash to submission data to enable secure external actions on submissions.
• The submissions (applications) list admin screen received upgraded styling to aid in readability and user experience of sync status labels and buttons, especially on smaller screens.
• The submissions (applications) list admin screen will no longer show action buttons when viewing the trash. A trashed post can be restored by the user to perform actions, ie: “Sync Now” or new Application Screening actions.
• Added WordPress filters to give user developers more control over the Duplicate Prevention methods in the routine that attempts to find an existing candidate in Bullhorn before deciding to modify or create a new candidate from an application.
• The filter matador_bullhorn_candidate_find_candidate is passed the full application object and found record from Bullhorn and can return false or an integer remote candidate ID. This filter will need to be used with the matador_bullhorn_candidate_find_candidate_request_params and matador_bullhorn_candidate_find_candidate_query to modify the scope and shape of the found records to test against. After finding a record or records that match the query, each record is looped through and run through this filter, with the first positive match returned as a found candidate.
• The filter matador_bullhorn_candidate_find_candidate_by_lastname is now available to turn off the last name check that is a part of our default duplicate prevention routine. This is helpful when a user’s site operates in a country where last names may be different in casual and formal contexts.
• User developers may now use a WordPress filter to force the candidate and submissions to be categorized the same as the job the applicant initially applied for. For example, if an applicant applies to a job with the category “Accounting”, when the applicant is created in the ATS database, the created candidate submission will also have the category “Accounting.” Pass true to the filter matador_applications_category_defaults_to_job_category.
• Added check to prevent the saving of empty application files. It is occasionally possible that a file with no contents could be submitted and these should not be saved to the application record.
• Changed the naming scheme by which uploaded application files are saved to the web server. Formerly, application files were saved to a secure uploads folder with a unique name built by prepending a unique character string to the start of the original file name. Now, each new application will create a folder with a unique name and store uploaded files in that folder without changing the original file name. This will provide the same level of security while also addressing concerns from users of the confusing and long resume file names.
• Fixed an issue where the description for the resume field on the application form now respects the user setting which allows a choice between …