We are excited to finally announce the release of Matador Jobs Pro 3.9.0 on Wednesday, March 5, 2025. This major release, our first in 14 months, contains 535 total changes, 363 files added, updated, or removed, and changes to almost 16,000 lines of Matador’s code!

If you are reading this before March 5, send us a Support Request if you’d like to test our Release Candidate with us!

An ATS Agnostic Future is Coming

Before we get off sharing all the news related to this release, we wanted to share some news related to our development priorities since the last year. Namely, in the near future, Matador Jobs will become “ATS Agnostic.” When we launched Matador Jobs in 2018 through today, it exists solely to work with the Bullhorn Applicant Tracking system. In late 2023, we began building a version of Matador Jobs that works well with other ATS systems. Our goal was to release 4.0.0 next, but we just aren’t happy with our ATS-agnostic version of Matador, so we plucked out everything else that was done and built 3.9.0. It is our expectation that 3.9.x won’t last long, as most of 4.0.0’s key features are almost ready to go.

What does that mean now? It means we’ve sorted Bullhorn ATS specific change logs into their own section, for now, and in the future, change logs will focus first on the core shared experiences of all users followed by the ATS-specific changes some users may experience depending on their connections.

Major New Features

Matador Jobs 3.9.0 contains three major new features that we’re sure you will really appreciate!

Visual Editor Blocks

We finally are confident in our Matador Jobs blocks, for use in the WordPress Block Editor. Our editor blocks have 100% parity to our shortcodes, and in fact add new features to customize display. Included blocks are:

  • Job
  • 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.
    • 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. 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 <select> 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 `CV`, `Resume`, and `Curriculum Vitae` for the word used to refer to the CV/Resume. Additionally fixed a typo in the output when `Curriculum Vitae` was selected for this user setting.

Settings

  • Added actions `matador_options_before_update` and `matador_options_after_update` which run only on the Matador Options screen and after the nonce is validated. This will make it easier for extensions to add actionable buttons to their settings without needing to do separate nonce checks.
  • “Toggle” type admin settings now automatically have an off default setting, finally solving an annoying issue we’ve been struggling with for three years.
  • Fixed issue that causes the screen to “jump” when user selects different tabs on the settings screen.

Bullhorn ATS Integration

Moving forward, changes to behavior for a specific ATS integration will be isolated into a separate sections of patch notes, as with Matador Jobs 4.0.0, Matador will support multiple ATS integrations. All items in this section apply only to sites integrated with Bullhorn.

  • “Edit” job button (which links into Bullhorn) is added to the Block Editor view of the Job Posting to ensure feature parity with the older Classic Editor.
  • The Application Sync routine may perform an API call to check if the Application being processed represents a Candidate that has already applied to the Job. If setting is turned on, a new Job Submission or Web Response will not be created when this is determined. This process requires an additional API call and only checks for the presence of an existing submission. Site admins that wish to customize this behavior, for example to only skip when there are matches in certain categories, can use the WordPress filter `matador_bullhorn_candidate_maybe_skip_submission` to customize the behavior when performing these checks.
  • Improved the method which is used to get Bullhorn Custom Objects.
  • Sets the JSON+LD Structured Data Job Location Requirements for Remote/Work-from-Home Jobs based on the job address.
  • When saving notes to Bullhorn we now set the action to Matador Jobs Note and set the author to match the matador setting for candidate owner.

Third-Party Plugin Integrations

  • Yoast SEO Premium will no longer notify or attempt to automatically generate redirects for job listings. This warning, while correct for most types of content, should not apply to Job Listings. Specifically, Google, and other search engines too, express a preference for a `404 Not Found` or `410 Gone` be sent expired and removed Job Listings.
  • Google Indexing API Integration now has added status monitoring feature to health page.

Security

  • Bugfix: Fixed bug where an empty `index.php` file is not created when an uploads directory exists but the empty `index.php` does not. The bug occurred because the check only ran during the recreation of the containing directory, not on every file save to the directory.

General

  • Replaced all WordPress intval() function calls with PHP 7+ (int) variable casting method.
  • Minimum PHP Version Bumped from 5.6 to 8.1
  • Tested up to WordPress 6.7.2

Update Now!

Matador Jobs 3.9.0 is released for automatic* update to all subscribers as of Wednesday, March 5, 2025. If your subscription has expired, renew it on your account page. If you find any issues, please send a support request.

* Please Note: some versions contained bugs that required users install manual updates. See here if you are having trouble receiving an automatic update.