Developer Commentary: Solving the Race Condition Issue at Intersection of Bullhorn, Indeed, and Matador Jobs

Beginning in early August, users of Matador Jobs who also use the Bullhorn Indeed Syndication tool to post their jobs to Indeed began seeing things work not quite as expected. We discussed this issue in a past blog post, providing guidance and work-around procedures while we investigated. Today, we can confirm that we’ve developed a solution that, once installed, will end this frustration for our users moving forward.

Recap: Bullhorn’s Indeed Syndication

When users of Bullhorn are ready to begin marketing a new job (role, vacancy), they use the Bullhorn ATS publishing process. During the publishing process, users are presented with a checkbox that allows them to also publish the job to Indeed.

As we understand it, when also published to Indeed, the job data is provided to Indeed via a Bullhorn-generated XML file that Indeed uses to import the user’s Bullhorn job data onto their platform.

Users of Matador Jobs have been using this feature of Bullhorn’s for some time without issue, but in the summer, this changed. Suddenly, newly published jobs would show up in the Indeed dashboard as “expired” even though they were brand new, active opportunities.

A Race Condition

Our theory as to the cause of these issues is that starting at some point in July 2020 Indeed or Bullhorn changed how it handled data from this feed resulting in a race condition.

A race condition is a type of computer bug that arises when a computer program, in order to work as intended, depends on two or more steps in a sequence to occur in order, and they do not.

We believe that one (or more) of the following changes occurred to make an existing race condition more likely or create a new race condition:

  1. Bullhorn, may have previously updated it feed on a schedule, but increased the rate of which the feed was been updated and/or provided the feed real-time, making an existing race condition bug more likely.
  2. Indeed, may have previously accessed the feed on a schedule, but increased the rate of which it updated its data from the feed and/or began accessing the feed in real time, making an existing race condition bug more likely.
  3. Indeed, which may have previously not validated the feed, began sending a “bot” to access the jobs pages, and sometimes did not find them as Matador hadn’t synced by the time the bot visited, creating a new step in a sequence creating or making more likely a race condition bug.

If we were to guess, we believe condition 3 is most likely cause, but we want to stress that this is only a guess.

Let’s recap for a sec how Matador Jobs works, and always has, since our launch in January 2018: Matador sets up a scheduled task called a “cron” that triggers a sync to Bullhorn automatically every 60 minutes. Any jobs newly published, or published jobs updated, closed, deleted, or unpublished in that time frame are added or removed from your site at that time. We do this once per hour because an API to Bullhorn is resource-intensive and we like to keep Matador as light as possible so it can run on all kinds of web hosts.

So, our system always had a short delay between publishing on Bullhorn and syncing to the site, so our theory is that sometime in summer, a change occurred where this gap in time became a problem. The updated race condition required Matador’s sync to complete faster than it was happening naturally.

Complex Problems Take Time to Solve

We at Matador worked with our partners at Bullhorn and, through them, spoke with representatives at Indeed, during the late summer and fall to try and figure this out. Progress was slow. While this was happening, our users would attempt similar connections, and these support requests usually ended in the various parties confirming to the user that their platform is not the cause of this issue.

This was/in, in fact true; if the issue was the result of a race condition between three separate pieces of software, all single parts of the puzzle could’ve been in perfect working order while, as a whole, the combination was not.

We assure you, our users, that despite the delays, we were proactive during this frustrating time. We identified alternate solutions and helped many of you set up these alternates. Our goal was always, however, to provide a solution, either ourselves, or by encouraging one of our partners to deploy one.

And, well, we think we found one.

Winning The Race

We found inspiration for a solution in the Bullhorn Open Source Career portal. The OSCP gets its data on demand via a javascript request, unlike Matador which syncs data locally on a schedule. Matador syncs data for both its speed and data uptime benefits, but the fact that OSCP was never a victim of this race condition meant giving it a closer look.

Our solution needed to preserve the cached local copy benefits of the Matador platform while being able to access data from Bullhorn on demand while also not consuming too many server resources that would result in a user being charged more for hosting or losing performance.

For the Matador Jobs 3.6.4 release, we’ve developed a way for Matador Jobs to request a job on demand when a certain URL structure is accessed by a visitor (human or bot). We applied this behavior to the unique URL structure we introduced in March for the Matador 3.6.0 release specifically for the Bullhorn Indeed Syndication tool.

Since 3.6.0, if your site has a jobs page at and a job URL that follows the pattern like, an alternate URL scheme is available where the Bullhorn ID of the job can replace the last part. When a job is found with that ID, a redirect will be made to the proper URL. So for Bullhorn job ID 1234 will automatically redirect to the job page at or to a “not found” error if a job with that ID does not exist.

With 3.6.4, if the job ID does not exist on your site, instead of telling the visitor (or bot) that the job is “not found”, Matador will now delay the response to the visitor while, in the background, it will make a call to Bullhorn to see if a job with that ID is available. If it is, Matador will import the job immediately, end the delay, and allow the visitor to visit the newly imported job’s page.

And that is how we will win the race, by putting up a roadblock when we think we are behind, and give ourselves time to catch up.

Important Note: Republish “Expired” Indeed Jobs

Please note: if you are a user of Bullhorn’s Indeed Syndication tool experiencing “expired” jobs on Indeed that are open and accepting application on Bullhorn and Matador, note that the upgrade to 3.6.4 will only prevent this issue moving forward and not retroactively fix these affected jobs.

To fix these affected jobs, go into Bullhorn and publish the affected jobs again. This will place the jobs back to the top of the Bullhorn Indeed Syndication XML feed and trigger Indeed to recheck them. This is a one-time task and only required for jobs Indeed shows as “expired” that are, in fact, not.

Final Notes From The Winner’s Podium: Release Timeline and Thank You

As of yesterday, we had three users beta testing this feature and with no reported issues, will begin releasing 3.6.4 immediately. Please log into your WordPress site and trigger the plugin update as soon as possible. If you are unable to update, make sure your support and updates subscription is active and you’ve input the license key into your Matador settings.

Thank you for your patience, understanding, and support as we’ve worked with our partners at Bullhorn and with contacts at Indeed to figure this out. We know some of you have been very frustrated and we appreciate your patience and we are so glad to be able to finally provide you a solution!

As always, let us know if you have further feedback, issue reports, or feature requests, as we are here for you, our users, and always committed to making Matador the best it can be for you!

Matador Jobs 3.6.4

Today we release Matador Jobs 3.6.4. While it contains a few bug fixes and a new developer filter, most importantly, it upgrades a feature to solve an issue occurring at the intersection of the Bullhorn’s Indeed Syndication and Matador.


This hot fix release contains one upgraded feature and one new developer filter.

  • Upgrade to handling of ID-based alternate URL structure to prevent 404: Not Found errors when a job is not yet synced. For more information on this patch, read our Developer Commentary on the topic.
  • New filter to extend allowed protocols on imported job descriptions. Users who wish to serve images via the data:// protocol are blocked from doing so by WordPress. This is for site security reasons. To bypass this security, users could use a global developer filter. With 3.6.4, users can now use the filter 'matador_the_jobs_description_allowed_protocols' to bypass this security only for imported job descriptions, minimizing the associated risk.


This hot fix release also includes a handful of minor bug fixes.

  • Fixed an error affecting the Employment Type mapping in Structured Job Data, which was resulting in some jobs on Google for Jobs not showing with the right employment type.
  • Fixed a backward compatibility with PHP 5.6, the programming language WordPress and Matador Jobs is built with. Please note, while we still extend support PHP 5.6, new features will favor the least supported version of PHP, currently PHP 7.3.
  • Fixed an issue causing Javascript errors in iOS Safari.
  • Fixed an issue causing some Bullhorn calls to fail in extremely specific server configurations due to an extraneous forward slash.

Get Your Update Now

As always, our users with an active Support and Updates license with their site activated will receive this update automatically. We recommend you keep Matdaor up to date to support all of our ongoing bugfixes and feature releases.

Bullhorn/Indeed Syndication Issues On Matador

UPDATE: The Matador Jobs team resolved “Issue 2” with Matador Jobs 3.6.4 release. Please update. Any jobs still affected by Issue 2 can be resolved by republishing those jobs in Bullhorn.

We are receiving widespread reports from our users who also use the Bullhorn Indeed Syndication (“Also Publish on Indeed”) tool that an update or change to that tool has affected their workflows.

There are two known issues, and one has a fix, while the other does not, however, we have recommended work-arounds.

Issue 1: Job URLs

Part one of this issue lies in that the Bullhorn Indeed Syndication service reports a URL for each job to Indeed. This is so that a job seeker can click on the job on Indeed and be directed back to a place you can apply.

Since our users want users to come to their website, this URL needs to direct them back to their Matador Jobs powered website. So, we’ve been instructing users to contact Bullhorn and ask them to update their Indeed Feed job URL.

You need to have a “constant URL” base with a “dynamic” portion for ID. If “constant” and “dynamic” in the same sentence is confusing to you; it is to us too. The good news is that we introduced support this for all our users on at Matador 3.6.0 in middle June of this year.

Your “constant” URL is the portion of a job URL before the “name” of the job. The “dynamic” part is the name replaced with the Bullhorn Job ID. Click through to any single job’s page. The URL might look like this:

Which means Bullhorn will need to use this URL for Indeed syndication:{ID}

Please note, the exact URLs for your site will depend on your settings. Some people use “gigs” or “opportunities” or “search-jobs” instead of “jobs”, for example.

Issue 2: The Race

So say you’ve done this first step… awesome! Ideally, the problem is solved, right? Well, no, because another issue is being reported by users, and this is that newly published jobs are being immediately “expired” by Indeed.

We currently do not know the cause of this second issue, but think it may be the result of a race condition, a type of computer bug where things must happen in sequence for a desired outcome and something occurs out of sequence. We are working with our partners at Bullhorn and, through them, with contacts at Indeed to understand this issue and develop a solution.

In the meantime, we have some work-arounds.

Issue 2 Work-Around 1: Republish

A solution we’ve found with help from Bullhorn support is that republishing a job causes Indeed to show the job as “active”.

Issue 2 Work-Around 2: Alternate Feed

Matador Jobs Pro All-Access users have access to the XML Feeds extension. Prior the Bullhorn Indeed Syndication tool, our users would publish to Indeed via this extension. Until a solution for the larger issue can be found, the XML Feeds extension works to provide an alternate path for job data to be read by Indeed.

Since the XML Feeds extension is part of All-Access, Pro users typically do not have access to it, but upon request, we will provide you the extension and enable it for your account until a better solution can be found.

We Will Keep You Posted

As we continue to work with our partners at Bullhorn and contacts at Indeed on this issue, we will find a solution and immediately provide it to you.

Thanks for your understanding and patience.

Matador Jobs 3.6.3

Today we are releasing Matador Jobs 3.6.3 containing an handful of bug fixes and improvements.


This release two feature refinements to compliment existing items. In general, we do not include completely new features in a “hotfix” release, but will refine existing behaviors if prudent.

  • The “Sync This Job” button will now be automatically removed from sites that deploy the developer filters that disable sync from updating jobs.
  • Matador will now check for the “ALLOW_PRIVATE” entitlement prior to skipping a “Private Candidate”. Prior to this, site operators could programmatically tell their Matador install that their API user had the “ALLOW_PRIVATE” entitlement but now Matador can detect that automatically.


This hotfix release includes a handful of fixes for bugs we’ve encountered recently as we deploy and distribute Matador to users worldwide.

  • The “Sync This Job” button will now always override the cached job data with Bullhorn data. Not technically a bug, this button used to not sync a job if the job had not been updated on Bullhorn. While this was working per our intent, users understood the button to also be a resource to correct local changes by refreshing Bullhorn data. The button will now always overwrite data with the data from Bullhorn.
  • We improved the “error” handling when “ALLOW_PRIVATE” is false.
  • We fixed an issue with how Matador loaded a 3rd party library which affected some web servers, including Windows-based web hosts.
  • We fixed an issue where the Consent Tab’s object name wasn’t being properly autodetected on some user’s sites.
  • We fixed two very uncommon issues that affected form fields dynamically created by the Advanced Applications Extension caused by a mismatch of data typing when converting Bullhorn’s JSON-based data into a PHP array.
  • We fixed a typo in a settings option label.

Get Your Update Now

As always, our users with an active Support and Updates license with their site activated will be able to receive updates automatically. We recommend you keep Matdaor up to date to support all of our ongoing bugfixes and feature releases.

Matador Jobs 3.6.2

Today, we released Matador Jobs “hotfix” 3.6.2 to all users. It contains a handful of bug fixes and the first of many changes surrounding our goal to use only inclusive language in our software.

Inclusive Language

In this release, we began our steady release of changes that remove insensitive language from our code, replacing it with inclusive, and in many cases, more descriptive terms or phrases.

  • All uses of the term “API Redirect Whitelist” (as a noun) is now to “Allowed API Redirect List”
  • All uses of the term “whitelist” (as a verb) is now “register”.
  • You will now see phrases like “you need to register your redirect to your Allowed API Redirect List” instead of “you need to whitelist your redirect URI” or “your redirect URI is not on the whitelist.”

Read more about our plans for inclusive language, and our reasoning, in our recent post on the topic.


This release contains two bug fixes possibly impacting your sites, as well as a few that we found but may not have even bothered anyone. Here are the two biggest ones:

  • Fixed an issue where the Matador Application form may not have always denied a form submission when Google reCAPTCHA was not filled out, resulting in an on-screen error message for applicants.
  • Fixed a backward compatibility handler for versions 3.0.0 and 3.4.0. A filter introduced in those versions for developers to use to customize emails was deprecated in 3.6.0’s big email-related code rewrite, but was given special handling for backward-compatibility into the 3.6.0 release. It was, unfortunately, not working as intended, resulting in some sites using the older developer filters to fail.

As always, complete patch notes are in the readme.txt file, which you can read by downloading the Matador Jobs software from your profile on our site or from the Matador Jobs folder on your site’s file storage.

Words have power – removing exclusionary language from code

Words have power

Thanks to the incredible conversations the United States and World are having right now about race and inclusion, it has come to our attention, as software developers, that some of the phrases we use are based on historically racist or classist terms and that our continued use of these terms is insensitive, unwelcoming, and exclusionary.

While insignificant in the giant list of things that need to be changed to bring about true equality and inclusiveness, we at Matador Jobs nevertheless feel we can begin to impact change by stopping our perpetuation of these negative language constructs in our software.

Our changes to exclusionary terms

Based on useful and interesting discussions with other developers around exclusionary language, we found that the items below are the biggest targets for adjustment. In many cases, these changes that can be made are actually more descriptive! Here are the key adjustments we are making in our upcoming releases:

  • Changing whitelist/blacklist to “allow list”/”deny list” to explain lists of explicitly allowed or disallowed items
  • Replacing master and master/slave to main and primary/secondary to explain relationships where one is an authority or primary source to a backup or secondary source.
  • Removing the use of “grandfather”/”grandfathered” to describe backwards compatibility or rights or access given automatically to a legacy user of a feature.
  • Instead of “whitespace” use “empty space”, “blank space”, or a more descriptive term to describe areas that are purposely empty, blank, or clear for readability or design, ie: a “line break” could describe space purposely used to improve readability of code or text.

First Up: “Whitelist”

Overall, to implement this effort, we have a relatively small to-do list, with a majority of the changes deep in the code where almost all of our users will never see it. There is one exception however, and it is all over our Bullhorn Connection Assistant wizard: the prevalence of the term “whitelist.”

In the case removing of this use of “whitelist,” we needed to first engage our partners at Bullhorn, as our use of the term was derived directly from their official API implementation documentation. Since we generate form emails in the Connection Assistant our users are encouraged to copy-and-paste and send to Bullhorn support, we needed to make sure that if we used alternate, inclusive language that it wouldn’t cause confusion when the email arrived at Bullhorn.

After very positive discussions with Bullhorn Support, they expressed full support of our removal of the term as they are undergoing a similar initiative to update documentation. We thank them for that incredible support!

On our next hotfix release 3.6.2 due out this week, we will replace the term whitelist in our Connection Assistant tool. Users will see the following impacts:

  • “Whitelist” or “Whitelisted” (used as a verb) will become “Register” or “Registered”
  • “[API Redirect] Whitelist” (used as a noun) will become “Allowed API Redirect List”

More on this Topic

As we do what we can to improve our code to root out insensitive language, we found the following resources helpful:

Matador Jobs Release 3.6.1 Live

Today we released Matador Jobs 3.6.1 to all our users.

We gave you all a preview of the release last month, and over the course of the last several weeks, we’ve slowly made the release available. We’ve taken this time to carefully make sure its major updates work consistently for all users.

We had roughly 20% of our users live on 3.6.0 as of late last week and we felt fully confident in making 3.6.1 (which included a late fix) available for auto-update to all remaining users. This occurred near the end of the day Monday, July 20, 2020.

Thank you if you helped us test and validate during the last month!

If you apply the auto-update and encounter any problems, please let us know via a support request.

Matador Jobs Pro Leads & Referrals Extension removed

Today, in response to changing laws and regulations around user privacy, Matador Software is removing the Leads & Referrals All Access Extension.

User Privacy and Refer-a-Friend

All-Access subscribers with a Bullhorn Enterprise-level account could access this formerly useful tool to allow individuals to refer-a-friend (or co-worker, colleague) for a position using a simple form. Like other refer-a-friend features, this would share the referred person’s information with the business offering the job, giving the recruiters an opportunity to follow up, while also sending them an email to invite them to visit the job posting.

The problem occurs when the referred user’s data is used, without their express consent, to a: be processed by the offeror’s website to generate an email, b: be used to track the referred user if/when they visit the site, and c: be contacted by an agent of the offeror for follow up.

A web site operator is obligated to get a user’s express consent before their data is collected or used under the rules of many privacy laws, including GDPR. While the extension was released at a time after-GDPR but before the patchwork of look-alike laws in various USA states and other countries, we justified its release based on customer demand while we made a note to warn EU users that the extension was not-GDPR compliant.

That said, in the last two-and-one-half years, a flood of new of user privacy laws from all around the world has made the list of “okay” places to use this feature smaller and smaller.

We cannot responsibly allow this feature to be released to new users moving forward. We are therefore removing it from our website.

Leads features to be re-relased

This extension also created customized “contact us” forms that site operators could use to solicit new hiring company’s business. This feature, while polar opposite of the refer-a-friend feature, was programmatically similar to the refer-a-friend features, and therefore we kept the two in one neat package. This “Leads” feature, however, does not run afoul of privacy laws.

In an upcoming release, we will introduce a new All-Access Plugin that will restore this functionality for Bullhorn Enterprise users. In the meanwhile, if you are a Bullhorn Enterprise user who wants to accept leads information from potential clients, please let us know and we can share the old extension with the expectation you will not use the refer-a-friend features.

Matador Jobs release 3.6.0 Preview

In the coming days, we’ll be releasing Matador Jobs 3.6, our next major release of the Bullhorn Marketplace Partner solution for connecting your Bullhorn data to your WordPress website.

We acknowledge the time between releases has been a little more than ideal, especially as we’ve shared privately with many of you that we intended to see a release much sooner. The time however, we promise, was well spent making sure each change was made carefully. In the case of some of the most seemingly simple features, like sorting jobs by date last published, the underlying adjustments to our core system were major.

This release will be final, we expect, by the time this post is a week old. If you’d like to download a preview version of it, let us know, and we’ll provide you a pre-release you can demo on your site.

What’s New?

Unlike release 3.5.0, which had one major new feature and a handful of more minor enhancements, 3.6.0 has six–yes six–major new features! Let’s break them down!

Integration with Bullhorn’s “Consent” Custom Object to Track Candidate Acceptance/Consent

Two years ago, with the implementation of the General Data Protection Regulation (GDPR) in the European Union, a worldwide tsunami of new rules for handling and protecting user data was ushered in. While tracking user consent is critical in EU, it is now critical in a number of US states and other countries around the world.

At our 3.0 release, with improvements in releases 3.1, 3.4, and 3.5, we’ve regularly added improvements to how Matador can help you keep up with this ever-changing landscape of laws, regulations, and best practices, most importantly documenting user actions of acceptance or consent during the application process.

Our progress in this area continues with our biggest step forward yet with full integration with Bullhorn’s Consent custom object. Here is how it works:

  • Turn on “Require Applicant to Agree to Privacy Policy” setting in the Matador Settings, under the “Applications” tab, if you haven’t already.
  • Optionally write a “Privacy Policy” page, and in the WordPress Privacy settings, set that page to as your Privacy Policy Page. Matador does not require a linked page, but will include a link to the page if enabled.
  • In your Bullhorn account, check the Candidate screen and see if there is a “Consent” tab. If not, contact support to have it added.
  • Matador will automatically check your account for the consent object, and if it finds it, will create an entry for each application you receive. If it doesn’t find it, it will re-check once per day.
  • The entries include important data about the consent the applicant agreed to with their application.
A consent record created from a Matador Application.

With this release, solutions previously available from releases 3.1.0 and 3.4.0 that used candidate custom fields are officially deprecated. This means, moving forward, we won’t update the older features and eventually remove them. We encourage you to update to this method, and it’s super easy to do so!

Few other notes about this feature:

  • Matador will check for the existence of the Consent custom object once per day until its found. If you have Bullhorn install the object and don’t want to wait for the next refresh, use the Transients Manager plugin (free) to remove the matador_bullhorn_candidate_consent_object transient.
  • Once set up on Bullhorn, the consent object should never change. Matador will assume it doesn’t.
  • Instead of automatically detecting the Consent object, a developer can manually set the API object name with the matador_applicant_candidate_consent_object_name filter. It expects a value from customObject1scustomObject10s.

At this time, only the “Privacy Policy” form field form will add a record to the Consent object. In a future release, we’ll add a way for our users to create a separate “Terms of Service” consent field. In the meanwhile, developers can create their own “Terms of Service” or other custom consents in the form and then process them and create consent records using the matador_applicant_candidate_consents_data filter. An example of a custom consent may be “I give permission to receive communication about this role in the form of SMS messages.”

“Work From Home” Jobs Optimizations for Job Schema (Google for Jobs Search)

Prior to this past March, “Work From Home” aka “telecommute” aka “remote work” was not quite in the forefront of our minds, especially during a job search. Now, however recruitment agencies are wanting to highlight jobs that are “Work From Home”.

The Job Postings schema, used by Google for Jobs Search and others to deliver accurate, relevant job search results, always had structure to highlight WFH jobs. Matador was previously unable to fully support this, but with the drastic changes to the industry in the last year, we put extra effort into extending our support moving forward.

Now Matador Jobs can determine, from your job data, if a job is WFH and broadcast this information in the Job Schema. Here is how it works:

  • In Bullhorn, modify your Job Posting field mappings to show the “On Site” option.
  • Matador expects the following default values of “On Site”, “Off Site”, and “Telecommute”. If there are more options and/or these are not your options, see below. Save your field mappings.
  • In your jobs, denote jobs that are WFH as either “No Preference” or “Off-Site”.
  • On the next sync, Matador will import these jobs and modify with the Job Schema to highlight WFH, which will be updated by Google for Jobs on their next visit.

In Google for Jobs search, these jobs will be shown to users seeking WFH positions explicitly as well as location-based searches in the same state (if USA) or country.

If your options for ‘On Site’ are different than ‘On Site’, ‘Off Site’, and ‘Telecommute’ (Bullhorn defaults), your developer will need to use the matador_bullhorn_import_telecommute_types to map your values to the scheme expected values. See the documentation for that filter in the source code.

To begin taking advantage of this new feature, all you need to do is update your job data with the on site values!

Advanced “Work From Home” Jobs Optimizations for Job Schema

The updates to the Schema explained so far, as we said, require no configuration to begin using, in fact it’ll happen automatically. That said, let’s talk a little more about how this works.

In Google for Jobs search, these jobs will be shown to users seeking WFH positions in a given state (in the US) or country (elsewhere).

What happens if the job is available to people in more states or countries? What if the position in New York can be worked by a WFH worker in Los Angeles? Schema allows you to set places your WFH job can work with a little extra leg work.

  • Open your Bullhorn field mappings for the Job Listing.
  • Set up a new customText field with a label like “WFH Location Type” and give it picker values of “COUNTRY”, “STATE”, and “PROVINCE”.
  • Set up a second new customText field with a label like “WFH Location Value(s)”. Allow free-form text input.
  • Make sure these new customText fields are visible and located near your onSite field.
  • Using the matador_bullhorn_import_location_requirements_fields filter, pass the names of the customText fields you’re using for Type and Value(s). See the documentation in the source for information on how to do this.

From this point forward, if Matador identifies an imported job as WFH, it will check if it has values set in those custom fields. If so, it will add extra data to the Job Posting Schema so that the job will show up in more relevant search results.

Let’s say you have a job located in France and workers from Belgium are also welcome to apply. If the WFH extra inputs are not set, the search will only return results for searches in France, but by using extra inputs, searchers in Belgium will also see the job. To set this job up like this, you’ll:

  • Set “On Site” to “Telecommute”, “No Preference”, or “Off Site”.
  • Set “WFH Location Type” to “Country”
  • Set “WFH Location Value(s)” to “France, Belgium”

Job ID based URLs

Website addresses should be human readable (for humans, but also to highlight keywords for search engines), so when Matador creates the URLs for your imported jobs, it creates something based on the job title. In this release, we added alternate URL schemes to support other integrations alongside default, human-readable functionality.

Jobs can now be found by appending the remote job id (ie: Bullhorn ID) to the jobs base URL. If yours jobs exist at and you have a job ID on Bullhorn of 1234, then will work as a link for that job. In fact, you will redirect to its human-friendly URL like automatically.

Jobs can now also be found by appending a query string to the jobs base URL with the argument of ‘xid’. For example, if jobs exist on  and you have a job ID on Bullhorn of 1234, then will redirect to its human-friendly URL also.

For forward compatibility with future support of additional ATS services, you further use the query string method and include an additional argument of ‘xsource’ to verify the external source, for example will ensure that xid of 1234 is a Bullhorn job.

This feature was added specifically to support Bullhorn’s publish to Indeed feature, but we see potential for it in many applications. For example, if a recruiter wants to email a job to a candidate, they could look up the job ID and hand-write the URL without needing to look up the human-readable URL generated by Matador.

This feature is automatically enabled on all Matador Jobs 3.6.0 sites with no setup required.

Job Date Source Option

We are excited to release what is likely one of the most requested features in the history of Matador: Job Date Source settings.

Let’s say you hired for a position at a company one year ago and the placement didn’t work out. The client contacted you to repost the role with the same description, salary, and job title. It makes sense to re-open the old record, right?

Well, since its release, Matador has set the job date from the dateAdded field, aka the date the job was created in Bullhorn.

When a job is reopened, it technically represents a new opportunity, but to a visitor of your site, it might appear it is old opportunity thats never been filled. With jobs sorted by date in both your Matador powered job board and on aggregators like Google for Jobs Search, this meant new opportunities were being listed at a lower priority just because they were created a long time ago.

With this release, you can select from multiple options for the job date. The options are ‘Date Added’, ‘Date Last Published’, and ‘Date Last Updated’. Our recommendation moving forward is to use the ‘Date Last Published’, which is changed every time you explicitly Publish (or Republish) a job in Bullhorn.

To use this feature, go to the new “Job Date Field” setting in the Matador Settings, Job Listings tab. Select your desired option. On the next sync, the jobs’ dates will be updated.

Major Sync Performance Improvements

The data Matador fetches from Bullhorn during a job sync is a lot, especially if you have a lot of open jobs. Once all the data is fetched and stored on your webserver’s RAM memory, Matador then must process it.

On some of our larger sites, including those with 300-1000 active jobs, there are occasional issues where their webhost would time out the syncs due to it taking too long. This is of course a huge problem!

Now let’s be clear, Matador is not your local Mom-and-Pop website app. While we’ve done our best to ensure Matador will work on as many web hosts as possible, some have configurations that make it hard for Matador to do its job. Some web hosts have “long process killers” that stop Matador at 10 seconds of run time. A site with 100 jobs may need over 10 seconds to complete, and a site with 1000 jobs may need a lot more! For this reason, we strongly encourage you use premium hosting when running Matador! You need a powerful webhost to ensure Matador has the power it needs.

That said, with this release, we found several ways to optimization sync, and we’ve seen subsequent syncs run up to 70% faster than the initial sync. There may still be some timeouts, but the number of the sites seeing these timeout issues are reporting an almost total disappearance of timeouts!

These improvements won’t matter to everyone, but to those who needed it, we know its welcome! To take advantage of this, simply update to Matador Jobs 3.6.0, with no configuration necessary.

Reworked Email

When we first built Matador, we build it for a handful of early-adopter clients. What mattered to them were priorities to us. Since these Bullhorn users had automations and routines set up for email, none of them needed Matador to send recruiter and candidate related emails. We knew some of our users would need email, but we didn’t have a client to help us battle test it, and for this reason, Matador’s email was simple out of the gate.

Though it worked, we soon found many users were constantly pushing the limits of our email system. We knew early on that a more robust Email implementation and rework would be necessary, but over time, we were able to patch in new features and added onto our original processing to add much-requested features. But each update propped up something that wasn’t built for how we were using it.

With this release, Matador email handling is completely rewritten. This solved several annoying bugs and added many paths for us build toward a future. Here are some highlights:

  • New settings added to set the default from “name” and from “email address” for Matador generated emails. This was previously the site admin unless changed via a filter by a developer.
  • When a site chose to use multiple recruiter emails sources, ie: “job owner” and “assigned user(s)”, sometimes the same email could be sent multiple times to the same recruiter while other times to no recruiter if the job had no owner or assigner user. Now the Email will send only one email per person and an additional setting is added for a “backup email” for when a recruiter email isn’t attached to a job.
  • The Mustache Templating Engine was added to Emails. This opens the door for a soon-to-be-released All Access Extension allowing our users to change emails from a settings screen, but also simplifies editing email templates.
  • Applicant & Recruiter Confirmation emails can now be sent either before or after the application syncs to Bullhorn. Emails sent after the sync can include a direct link to the new Candidate profile inside Bullhorn.

Easier Button Styling

Theme developers creating rich, unique Matador Jobs-powered sites have found one pain point when developing customizations: buttons.

Many websites use utility classes–like Bootstrap’s btn class–to style buttons. Matador’s default templates cannot guess the name of your button class, so if a user wanted to match button styles they previously had two options:

  1. Update the Matador templates via overrides to add the utility classes to the buttons, or,
  2. Modify their CSS to apply button styles to the Matador button style names.

With this update, we offer theme developers a much easier way. By using the new filter matador_template_button_classes filter, developers can apply global button classes to all buttons created by Matador and/or specific classes for primary, secondary, and tertiary (currently unused) styles. Here is an example:

Bug Fixes & More

Are you done yet? Actually no! We also were able to do the following as well:

  • Matador now plays more nicely with Yoast SEO by injecting our Job Posting Schema into the overall Yoast SEO Schema object. This will happen automatically with no configuration required when Yoast SEO is installed. This change may improve organic search traffic as well as fix missing company logos on Google for Jobs listings.
  • In WordPress on an “edit” job screen, you can now request a refresh of that job by clicking the new “Sync Job” button. Since, for some sites, a full sync is time consuming, this is an easier way to get that one update live on your site right away.
  • We found and fixed a handful of PHP 7.3 compatibility issues. The Matador team is keeping a keen eye out for PHP 7.4 and 8.0 issues. Whenever possible, use the most recent version of PHP for best speed and security.
  • We fixed an issue where an edge-case implementation of the Matador application shortcode on custom pages did not read query string values or connect applications to jobs.
  • We fixed an issue the hidden resume/cover letter file inputs weren’t completely hidden. They actually were, but if a theme developer applied certain rules to it, they could appear. Then, when said developer wanted to re-hide that field, they would display:none it. According to our form validator, a display:none form field is not validated, allowing forms without the required resume to be submitted. This wasn’t a bug, but we found an opportunity to “hide” the field better so such a silly thing may not happen again. Thanks Heidi, by the way, for your patience as we figured this out! It was a doozy!
  • Some fixes for PHP 7.3, 7.4, & 8.0 compatibility.
  • Several more minor features and bug fixes, including several to support developers for new extensions and themes, are also included, but not as noteworthy.

What Now?

Matador Jobs 3.6.0 is available in its release candidate today. Contact us by email if you’d like to deploy it at the risk of finding one more bug we need to fix.

We expect to release it to automatic updates via logged in users with active license keys next week.

To all our users who have been patiently waiting for this release: THANK YOU. We worked hard and we know you’ve been waiting for months for this. We didn’t want to give you something half-baked. We appreciate your understanding!

Release notes: Matador Jobs 3.5.6

Today, we released Matador Jobs 3.5.6. Many of our users were distributed an early version, however, so to lots of you, this isn’t news! This release held back because it was something we were very, very cautious to release, due to it necessarily containing a backward-incompatible change. Overall, this release has three notable bug fixes and a few others.

When the “Get Description” function does too much

Matador Jobs has a number of “public” functions. They are like tools in a toolbox for theme developers to use create rich, custom experiences. While lots of users never dive into those, choosing to instead use the default layouts provided by the Matador shortcodes, these functions are a key part of the promise we make to you when we say that Matador is fully customizable.

One of these public functions, however, behaved oddly since the day 1 release of Matador. Its name, description, and purpose implies that its job was fetch or display the job description, but instead it could also get the job information block and/or the job navigation block.

There were a number of work arounds, and whenever someone pointed out the confusing behavior that was, frankly, contrary to what our users expected, we’d give them the work-arounds.

Matador is still young, and while there are lots of you, there are lots more coming. We had a conversation with a developer building a Matador site and he convinced us that we needed to fix this, even if it would be a little painful.

This release contains a backward-incompatible change to fix this problem. This is our first of what should be few, if any, ever. Backwards-incompatible changes are changes that “break” something. Its possible this release will “break” the look and feel of your site.

Have no fear! For the next six months or more, you will be able to delay this update. There is an “Upgrade” option added to your Matador menu and give the opportunity to choose when this change is applied. It’s not complicated to prepare your site for the upgrade. Check out our upgrade guide.

More Changes In Response to Bullhorn December Update

If you’ll recall from the 3.5.5 release announcement, prior to 3.5.5 Matador stopped working due to changes made to Bullhorn’s API a few days earlier. The 3.5.5 release restored service, but the 3.5.6 release fully addresses all the changes made in December to the Bullhorn API so that we keep up with their similarly frenzied development cycles!

Shortcode Pagination on Front Page Works

The way WordPress treats the front page is different than the rest of the site, so we found that when our users deployed Matador on the front page of their site that sometimes pagination and search would not work. This hotfix includes a fix for that issue.

Other Updates

Typically, we collect a small number of bugfixes and hold them for release when prudent. Included in this update were the following bugfixes that made came about during the development:

  • Fixed issue with the “backfill” argument on the shortcode and function to list jobs.
  • Fixed issue where a public function was requiring an arguments array even though it wasn’t necessary and documentation declared it optional.