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

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.

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!
  • 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.

Matador Jobs 3.5.5

While under no circumstances would we find it prudent to issue an update to our software the weekend before a week of celebration and relaxation for most of the world, we must announce the release of Matador Jobs 3.5.5. We strongly encourage you all to please update your sites immediately!

An Emergent Issue Discovered

Beginning yesterday, we saw a number of our sites begin to encounter failures when submitting applications to Bullhorn for candidates who already existed in their Bullhorn account. This was causing our routine to encounter a breaking error, resulting in all applications affected becoming “stuck” and, for sites with the “sync applications” option set to “submit applications immediately”, was causing a site-breaking error for applicants.

Beginning Thursday, December 18th, Bullhorn began rolling out the 2019-December updates to the ATS and a majority of the clusters got the update on Friday, December 19th, which was when the issue was first reported to us. We feel this is no coincidence, and may imply one of the following:

  • We were not notified of a change to the API and we could not prepare our users for the update.
  • The update caused an error on Bullhorn’s platform, and we must wait for them to fix it.

After hours of attempts, we were unable to determine a fix for the issue. We submitted various notice to Bullhorn techs requesting assistance. Because we suspect the holiday may cause this issue to persist for a while, we turned our attention to finding a work-around to restore the functionality of Matador in the interim.

Note: You Lost No Data

Prior to the first release of Matador, as told in our story, Paul and Jeremy ran precursor solutions that would lose applicant data when communication with Bullhorn failed. One of Matador’s biggest launch features was to store application data locally until a successful communication with Bullhorn completed. This ensured that no data would be lost.

This is true for this issue too! You lost no data!

The Fix

With this release, we improved error handling for errors like these and notably gave Matador the ability to continue when a failure of this kind occurs. What does this mean?

  • If Matador cannot update the existing candidate (updates usually are of form-submitted information like new phone numbers or emails), Matador now can skip the update altogether. This means the new phone or new email will not be changed, but can still be accessed in the resume and would be included in the recruiter email notification (if you have those turned on).
  • Now that the process is able to continue, new files (resume, etc) will be uploaded to the candidate, and the candidate will be submitted to a job via a submission or web response depending on settings and if the application was connected to a job.
  • Your next automatic sync with Bullhorn will scoop up and sync all the previously “stuck” applications, and if your settings remove completed applications, they will be removed as should be.

Next Steps Regarding Restoring Functionality

We have support tickets submitted to Bullhorn and expect a response at the start of the week. We will continue to monitor this situation and restore the intended behavior you’ve come to expect as soon as we are able to. Thank you for your understanding and your support.

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 already certified for release but that we intended to save for a post New Year’s update.

  • Fixed an issue where attributes that inform the client-side form validator script were not included for form fields of the “select multiple” type. If your application contains form fields of that type and it has attributes defining it as required, this will now produce proper error messages for users trying to submit invalid forms.
  • Fixed another issue around the handling of candidate skills as returned from the resume parser. When the failure was encountered, Matador continued, so no applications were held back as a result of this issue.

Matador Shout-out in Bullhorn Tech Stacks Feature

Great to see one of our longtime clients, Bridgeview IT, included in Bullhorn’s useful new Tech Stacks feature.

Many thanks to Tim Glennie at Bridgeview for such a positive shout out for Matador Jobs. (Click on the Marketplace partner logos in the Tech Stacks examples for client comments and partner details).

Quote from Tim Glennie "Paul's team did a great job of integrating their tool into our existing tech stack. They are always optimizing the tool and helping us convert traffic from our site into quality candidate submittals and client leads."

Tech Stacks offers real life examples of how Bullhorn customers are leveraging the Marketplace’s Bullhorn partner ecosystem. It aims to provide inspiration and helpful information.

Needless to say, we are delighted to see Matador Jobs included.

If Bridgeview’s reflections on using Matador pique your interest, please reach out to us and book a demo.

Matador Jobs 3.5.4 Release

Tomorrow, following final feedback from a handful of our customers, we are releasing Matador Jobs 3.5.4. It contains a handful of changes, including two security updates and a handful of bugfixes that improve the stability of Matador.

Edit Friday, December 13, 2019 16:30: During final testing and feedback, we discovered continued issues around one of the bug fixes included in this release. This feedback was able to, we believe, finally quash this bug. That said, since everyone is going home for the weekend, we will be delaying distribution of this update until Wednesday, December 18th.

Security Fixes:

Security is important to us at Matador Software. While no code written is perfectly secure, we do our very best to follow best practices related to security and always research and question major decisions we make. We’ve also had our code reviewed by many developers who give us feedback and generally agree: Matador was made with security in mind. That said, we do find opportunities for improvement, and this hotfix release contains two security updates we feel will make your site safer:

“Message to Recruiters” No Longer Accepts HTML

We always envisioned the “Message to Recruiters” optional application field to be used also by businesses seeking to allow copy/paste HTML or Text resumes. That said, we’ve actually never seen anyone deploy Matador in this way.

For that reason, the data was filtered and sanitized (programmer speak for “made safe”) using fewer rules than other fields. While we filtered out potentially dangerous HTML and Javascript code, most HTML could be passed into your emails and Bullhorn. This was, I repeat, by design.

A client reported a spam application submission where the spammer was able to use HTML to mask a dangerous URL as a clickable section of text that did not appear to be a link (text was black and not underlined). The client did not click the link, but we agreed with them: that is not okay.

For your safety and security, the “Message to Recruiters” field will now remove all HTML. If you want or need a field where a user can submit HTML, eg: an HTML resume and/or code answer, let us know and we can help you create a custom field with that functionality.

Search Terms Sanitization Hardened

The search form submissions use HTTP GET requests, which appends search parameters to the URL. This is so you and your users can share specific searches with others. When investigating an issue a client was experiencing that ultimately was unrelated to Matador, we did find an a place where we felt we could improve the security of this functionality. We believe that there was not technically an exploitable opportunity for hackers, but we’d rather add an extra layer of safety where it seems prudent, and did just that.

Bugs Squashed:

In addition to those two important security changes, we also included 6 bugfixes in this release:

  • Fixed an issue where if an applicant put more than one space in their name, their application could fail in two ways, first in preventing a duplicate, and second in saving altogether. Protections were put in place to remove unnecessary spaces prior to processing a compound name.
  • Fixed an issue where a parsed resume might contain an empty “skills” object, which was causing some aspects of the Matador application processing to fail. We added protections to prevent failure and handle the empty skills object gracefully.
  • Fixed an issue causing Application Syncs to continue syncing to Bullhorn even when the setting was set to “off.” Oops! Fixed!
  • Fixed an issue where security escaping for the search form shortcode was too strong and disrupted the expected output. We were escaping output three times, and one of those escaping procedures was breaking the search form when a certain combination of options were selected. (See, sometimes we’re so security conscious we break things in the name of safety!)
  • Users of our WP Job Manager add-on will note that we removed options related to JSON+LD because WP Job Manager handles it separately. The settings could be set, but were ignored, so to prevent confusion, they were removed.
  • Users of our WP Job Manager add-on will also note new settings related candidate and recruiter email notifications were added. These options existed in Matador but were not being offered to WPJM users due to a bug.

Other Notable Changes:

  • Two new filters were added to allow for more granular handing of job data on a sync. One filter, related to the same behaviors, recently added in 3.5.0, was also deprecated and replaced with a more descriptively named filter. This replacement, however, inverted the boolean. The old version’s default was a false, while the new version is a true. Deprecation handling was added so if you were using it, there is no need for a change to your code any time soon.
  • The connection assistant offered an option to use the WEST USA 50 cluster. Unlike every other API datacenter, which even if not associated with your account, could be logged into and otherwise work as expected, WEST USA 50 could not be logged into. We theorize it is because you must be on WEST USA 50 to log in. We’ve temporarily disabled this option until a user associated with WEST USA 50 can help us test the option.
  • We improved descriptions of the setting on the options page related to when applications are processed.
  • We improved documentation in the template-functions.php file, which is a go-to file for developers implementing Matador. It is our most documented file, and we are constantly working to improve it so your developers are able to easily implement Matador.

Matador Jobs 3.5.3 Release

Today we are releasing Matador Jobs release 3.5.3. It contains a handful of bugfixes and internationalization changes to improve your Matador-powered website.

New “Feature”

While we follow semantic versioning, in a round-about-way, this release contains a new, backward compatible feature.

In version 3.4.0, we included a chunk of code designed to support more and more customizable form fields using our Advanced Applications extension, specifically form fields that in Bullhorn represent “to many” data types, like Candidate Categories or Skills.

Up to that point, no one was using it, so we didn’t have any real-world test cases for it, so we reserved our announcement until that happened. Since the 3.4.0 release, we had an opportunity with two clients to test it and they found a few bugs that were fixed in this release.

With those bug fixes, we can feel more confident in supporting a wider group of users, so we are making known the feature is now in “beta”. Like I said, its new a “round-about way”; its a feature that was technically already in the code, needed some bug fixes, and now is widely known.

If you are an All-Access subscriber and want help adding questions like “what of our business sectors would you categorize yourself into”, reach out to us.

Bugs Squashed:

  • We added error handling for the event where a candidate with “Private” status could not be modified by Matador. It still can’t, but now the candidate sync won’t fail. Let us know if you use Private status on candidates, and we’ll help you work with Bullhorn to enable API-management of private candidates.
  • When the Matador Application is generated dynamically, like by Javascript, there was an error that could be caused by passing the Bullhorn Job ID but not the WordPress Job ID. Now either one or both will work.
  • We found and fixed an error related to recruiter notification emails, where the email would fail to send if certain settings combination were right.
  • We were notified on an error by Eric C of Visual Notion where multiple taxonomy terms, comma separated passed into the shortcode would not show jobs from all categories even though the same behavior worked when passed into a search form or via URL. We fixed that. Thanks Eric!

Other Notable Changes:

  • We made a number of updates related Internationalization. Specifically we fixed issues causing four text strings to be not translatable and updated several translations in our Dutch language pack based on feedback from our users.

Matador Jobs 3.5.2 Release

Friday, we released Matador Jobs 3.5.2, a second patch release to the 3.5.x version of Matador that addresses a few issues found since 3.5.0’s or 3.5.1’s release.

Bugs Squashed:

  • We fixed an issue where a conflict could be created between our implementation of the open-source jQuery.validate() JavaScript library, which we provide for the purpose of form validation, and other plugin or theme use of the tool. When this was present, no forms would get validated, failing to notify the applicant when insufficient data is provided.
  • As part of this, we fixed a security issue where, either by disabling Javascript, failing to load the validation code, or maliciously manipulating form data, a user could bypass the required acceptance of the privacy policy fields.
  • We fixed an issue where an invalid email address submitted to the form would be properly rejected by Matador for security reasons but the user would not be notified.
  • We fixed an issue where multiple “admin notices” would stack, causing an overwhelming list of notices when logging in.
  • We fixed a bug where, during a specific combination of arguments, the Matador Jobs shortcode could fail due our handling of the many different ways the single shortcode is designed to work.

Other Notable Changes:

  • We changed a behavior associated with how Matador notifies you of failed communications with Bullhorn. Previously, our intent was to have every communication failure present an “admin notice” to a logged in WordPress administrator. This meant a warning, “your Matador Jobs is disconnected from Bullhorn” would be displayed. This error persisted even after our build-in connection recovery tool successfully re-established connection. With this release, if the connection recovery tool recovers the connection, the admin notice will be removed.
  • Fixed a spelling error in the default label for an uncommonly used application form field.

Matador Jobs 3.5.1 Release

Friday we released Matador Jobs 3.5.1, a patch/hotfix release to address a few issues found since 3.5.0’s release last week (or before) and add a new filter hook for increased customizability of Matador for our users.

New Features:

The sole new feature of this release was the addition of the new filter hook matador_data_source_status. This filter extends to the user the ability to change the status of the Candidate or the Job Submission created in Bullhorn from the default of either “New Lead” or “Submission” to any other value. Its second argument is $entity, and can be used to fine-tune your customization to either the candidate or submission objects.

Bugs Squashed:

  • We fixed an issue where, in certain versions of PHP, a namespacing error was causing an error message during job submission. Many of our users say multiple duplicate submissions, and this error may have caused user behavior to re-try.
  • We fixed an issue where the Candidate Traffic Source Tracking tool, which was extended for use with the Leads and Referrals All-Access Extension, was not properly referenced when creating new Leads objects.
  • We fixed an issue, introduced at the release of Matador Jobs 3.1.0 but only reported to us this week, where a recruiter email notification could fail when the WPJM Integration All-Access Extension is in use.
  • We fixed an issue, also created at Matador Jobs 3.0.0 release, where both the wrapper <div> and <form> element of the search form shared the same class name. We renamed the class for the containing <div>. This was a difficult bug fix to approach, because any of three logical approaches to fix it were all backward-incompatible. We encourage our users, upon upgrading to 3.5.1, to check the visual presentation of their search form, and if you notice a change, your CSS may need a simple change. If you need help, please let us know.

Matador Jobs 3.5.0 Release: Introducing Source Tracking

Matador Jobs 3.5.0 is the second major release of Matador Jobs in 2019, and our fifth overall major release since our launch in January 2018. We’ve had various pre-release versions out for testing for months, and we finally believe its ready for everyone! Let us introduce you to some of the highlights of this long-awaited release.

New Features

We consider a feature to be a change that adds usefulness to Matador for its users. Some features are simply new filters or actions most won’t use, while others are completely new tools everyone will find value in. 3.5.0 includes a lot of both!

Candidate Traffic Source Tracking

The biggest addition to Matador Jobs 3.5.0 is what we call “Candidate Traffic Source Tracking.” This new tool will attempt to determine where a visitor to your website originated, and pass useful data about that visit along to their Candidate and Job Submission or Web Response records in Bullhorn, allowing you, the site operator, to better understand where your traffic originates from.

Any website operator should monitor traffic sources, including and especially when you are pushing advertising onto your website. Generally, it is recommended you use Google Analytics or other traffic monitoring tools to do this. But even more important is knowing how to derive useful data from reports generated by those tools, and that is not easy.

Matador’s “Candidate Traffic Source Tracking” does not replace those tools, but it does provide an additional layer of tracking for your traffic that, unlike Google Analytics or similar tools, can actually communicate its findings into Bullhorn data.

Let’s say you are purchasing pay-per-click ads from an advertiser. They’ll have you install a “pixel” to your site so that they can follow traffic they initiate back to your site, but once that traffic is on your site, then what? An important step to purchasing ads is ensuring that once your paid traffic gets to your site, you get the desired result. This might be a sale, a newsletter sign up, etc. For a person driving ads to Matador-powered job listings, your desired result is a job application. Now, with the right setup, when you see a new candidate, job submission, or web response from a submission on your website, you will also be able to review the “Source” field on that record and know if that user found you because of that ad, your Google for Jobs listing, or something else.

There is a lot more to this, so check out our new help doc for Using Candidate Traffic Source Tracking.

Other New Features

While the “Candidate Traffic Source Tracking” is huge, we didn’t stop there. Here are some other changes that will power up Matador for you and your site:

  • A new setting lets you choose how the Job Category taxonomy is populated. Now you can populate from either the original “categories” value, or Bullhorn’s new “published category” value. This is especially helpful for newer Bullhorn customers who are using new workflows.
  • The Job Location taxonomy can now accept the value of “Job General Location”. This allows you to create taxonomy terms like “Phoenix, AZ” where in the past you could only create “Phoenix” or “Arizona”.
  • The Hiring Client Corporation name is now saved into job data, should you wish to create queries based on the hiring company or display the name of the company you’re hiring for. This is not displayed to the customer unless exposed by your developer.
  • Application processing now checks if a submitted resume is under 1mb (1024kb) and does an additional server-side check that the resume is of a valid extension. This fixes two issues caused by extremely large resumes and resumes that had a valid physical extension but a mismatched MIME type.
  • Previously, when an application was submitted to Bullhorn and a matching candidate was found, the name would not be updated with new data. In order to allow for subsequent applications to append a middle name, name suffix or prefix, or update a first name from a nickname to a legal, given name, name can now be updated by data from the resume.
  • In 3.4.0, we introduced a method for a site operator to track the most recent acceptance of the Privacy Policy and Terms of Service. This was tracked into a Bullhorn candidate customDateXX field. Now, this can also be saved into a customTextXX field, and the value can be filtered to be simply TRUE or 1 if needed. Props to Scott R for the feature request!
  • Email confirmations to recruiters can now also be sent to the “Published Contact” in addition to “Job Owner” and “Assigned Users”.
  • The matador_jobs() function, and [matador_jobs] and [matador_jobs_*] shortcodes now accept a new parameter ‘paginate’. Pass false, “off”, or “no” to turn off page navigation when a job query can produce more results. Default is true, or “on”. (Some may consider this a bugfix, but our use cases for the shortcode were not clear in prior versions.)
  • The matador_jobs() function, and [matador_jobs] and [matador_jobs_*] shortcodes had the ‘limit’ parameter deprecated and renamed ‘jobs_to_show’ and the ‘minimum’ parameter deprecated and renamed ‘backfill’. This change, along with the addition of the ‘paginate’ parameter, helps to create more clear use cases while limiting confusion.
  • The text input fields in the Matador Search form are now wrapped in <div> tags, matching formatting for the taxonomy drop-downs and allowing greater control over styling to template designers.

That isn’t everything, but it covers the major changes! So now, let’s talk about some squashed bugs.

Bug Fixes

Matador is a big piece of code, and bugs are sure to exist. As Matador’s user base grows, our bugs are identified and quickly fixed. Here are some highlights:

  • Fixed an error where the Jobs Structured Data would not honor the setting ‘”Hiring Company” Data Source’ in certain cases, resulting in the Hiring Company Name, and not the Agency Name, being included in the structured data in certain cases. Props to Phil V. for the bug report.
  • Fixed issue where the new [matador_jobs_listing] and [matador_jobs_table] shortcut shortcodes were doing each other’s behavior.
  • Fixed an issue where the Bullhorn API would return a non-breaking warning when Matador updated an existing candidate in Bullhorn, which generally happens when an applicant applies for more than one job in the same 2-year period. This was not causing any issue at this time, but could in the future.
  • Fixed issue where taxonomy drop-down menus with method set as “link” would fail to trigger page reload automatically.
  • Fixed an issue where large resume file sizes (larger than 1mb) would cause a Bullhorn Candidate/Submission sync to fail. Now, sync will continue, but may fail completely later on if not enough user data was required by the form. (Related, also, the new filesize check feature, listed above.)
  • Fixed an issue where job description would not properly display when using the [matador_jobs] shortcode or the matador_jobs() template function outside of a standard loop.
  • Generally refactored how uploads are stored on the server to fix filesystem issues when a user hosted on a Windows IIS server environment. Note: Thank you to this user for allowing us to fully test Matador on IIS for the first time. While we still don’t officially support IIS, we can confidently say Matador works on Windows hosting.
  • Fixed an issue affecting the frequency at which local application data was automatically deleted.
  • Fixed an issue causing some intended HTML to be escaped, causing a visual error, when using specific settings with some Matador Shortcodes.

Other Notes

In addition to these new features and bug fixes, here are few more notes about this release:

  • Matador is tested up to WordPress 5.2.3
  • Matador is tested up to PHP 7.2.18
  • Matador now requires PHP 7.0+. While it will continue to work on PHP 5.6, all new major features will be developed to PHP 7.0+ specs, including the “Candidate Traffic Source Tracking” feature. That means these new features will not load in PHP 5.6 environments. We will completely require PHP 7.0 in a future version, so start upgrading now, if you haven’t already!
  • Matador now supports the new Bullhorn datacenters added recently. Note: Bullhorn is making it more difficult to determine your datacenter, and we are working on a method to determine datacenter automatically in a future update.

Updates to Matador Jobs Pro All Access Extensions

Given the size of this update, many Matador Jobs Pro All Access extensions also saw minor or major changes with today’s release.


  • Now tested up to WordPress 5.2.3
  • Requires at least Matador Jobs 3.5.0
  • Updated how jobs are searched, if applicable, based on changes in core that prevent duplication of jobs.

XML Feeds

  • Now include utm_* variables in your feed URL, ie /feed/?utm_source=indeed&utm_medium=aggregator to take advantage of new Candidate Traffic Source Tracking.

Leads & Referrals

  • If reCAPTCHA extension is enabled, add reCAPTCHA to forms generated by Leads & Referrals.
  • Updated deprecated filter name.


  • Force the reCAPTCHA to be the last field in a form, always.

Advanced Applications

  • Fixes bug for when site is not connected Bullhorn, settings page can still load.
  • Better support for associative field types, notably categories and skills.
  • Number of additional filters and actions.
  • Number of bug fixes.

Looking Forward

Looking forward, we have exciting updates in both the next week and in the next few months.

Two New All Access Extensions

Next week, we will be releasing two new All Access Extensions that All Access subscribers of Matador will be able install to improve and extend Matador’s usefulness.

The first is our Social Web Suite integration. Social Web Suite is a powerful social sharing platform for WordPress. Users of Matador who would like new job opportunities to be auto-posted (or otherwise easily shared) to social media, including LinkedIn and Twitter, may find this a powerful tool to add to their site.

The second is called Company Profiles. This add-on will help web site operators highlight the companies they are hiring for. While we know some users of Matador choose to hide this information, some find value in promoting the company alongside the job. Company Profile will import information from the ClientCorporation record in Bullhorn as well as give site-level tools, like adding a company logo, and build a profile page for the company while showing jobs for the company.

Roadmap for 3.6 and beyond

With 3.5.0 officially launched, we are also looking forward to working on a few key new features and enhancements we want to put into your hands soon, some we hope by year-end. They include:

  • WP-CLI commands. WP-CLI is a command-line management tool for WordPress sites, and a tool of choice of highly efficient WordPress developers and hosting companies alike. Not only do we want various commands like connect, disconnect, and sync available to WP-CLI users, we also want to provide WP-CLI commands for the purpose of setting up true CRON tasks that are run at the server, as opposed to site, level.
  • REST API. In order to support the next items on this list, we will be adding a custom endpoints for the WP-JSON REST API. This will help us add support for Gutenberg and asynchronous data loading, but it will also enable users to push jobs to more external sources (ones that require JSON as opposed to XML) as well as build “headless” WordPress sites.
  • Gutenberg support. Paul and I both love WordPress’s new editor, code-named Gutenberg. That said, Gutenberg is for editing posts, and for a tool like Matador that only imports posts, it isn’t really our thing. That said, we will be adding custom Gutenberg blocks to supplement our shortcodes and exploring how we can support the Gutenberg editor for your jobs.
  • AJAX/asynchronous loading for job data in shortcodes. If I were to describe the last few years of WordPress, it could be told in the development of Gutenberg and the surge of Managed WordPress hosting. The former we’ve just talked about, but the latter matters also, because with Managed WordPress has come aggressive caching to improve WordPress load speeds. We’re finding that users who employ the Matador Jobs shortcodes to power jobs pages are sometimes not seeing their cache clear when a job is added. This is easily fixed by a server-level setting, but we plan to circumvent this need by beginning to also load job data asynchronously upon page load. This also will give us the opportunity to extend more robust, near-instant search results and sorting to your pages, improving the user experience.
  • LUCENE search. Ask any WordPress developer how good search is in WordPress, and they’ll say “it isn’t.” That is because truly relevant searching is a difficult task to accomplish generically and instead varies greatly on each site’s data structure. For this reason, WordPress search is simple to a fault. We aren’t going to try to solve that problem, but we are planning and pass user searches asynchronously into Bullhorn’s new LUCENE search tool and get results based on Bullhorn’s robust search results. We aren’t sure yet if this will be an included core feature or a new All Access add on, but we will be getting to work on this very soon!


Well, I feel like I’ve been typing for days. In fact, I’ll admit, we’ve been “done” for about 10 days and the only thing holding back the formal release has been this incredible project of writing these release notes!

I hope you can see how hard Paul and I have been at work on Matador, even though some of you haven’t per se heard from us lately. And we’re definitely not done yet; there’s lots more to come.

Thank you again for all your support, trust, and in some cases, patience, as our small team builds something amazing for you and your business.