Matador Jobs Lite

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 …