Matador Jobs 3.7.0

On Thursday, February 18th, 2021, Matador Jobs 3.7.0 will release for auto updates to all active subscriptions. This release contains several new features and bug fixes to improve your job marketing and candidate data collection while also improvements that help ensure greater up time. Keep reading for a tour of some of the new features!

Improvements to “Remote/Work From Home” Marketing

Each major release since 3.5.0 has included improvements to our handling of “Remote” or “Work From Home” roles. With 3.7.0, we provide a handful of expansions or improvement to these features, including:

  1. Enable a new Setting to add a second Location tag called “Remote”. This means in your locations filters or drop-down, “Remote” will become available for users to select.
  2. If you use the Job Information bar, an information bubble will be added for jobs that are remote. This “Remote” bubble will be added between the Location and Job Type.
  3. A new job meta field isRemote can be used by theme developers to highlight remote jobs.
  4. Additional CSS classes are added to remote jobs so theme developers can style them differently in ways that make them stand out.
A Matador Jobs 3.7.0 site with a “Remote/Work From Home” Location

For a full list of Remote/Work From Home job marketing tools, and instructions on how to configure your Bullhorn account so that Matador Jobs can detect your Remote/Work From Home jobs, see our new help document on the topic.

Job Search by ID

While some sites will not prominently display the External ID (Bullhorn ID) of a job, many sites including those that use default layouts show this prominently.

Now you may add a search field to your job search form where users can search only by Job ID. Search results will return only the one job that matches that single ID.

Search form with “Job ID” search box.

This can be helpful for your recruiting staff to easily find a job’s page on the website, like to grab a link for social sharing or to email it to a user, and is also helpful for your users who might take notes of job IDs they want to revisit later.

Job “Age” Field

We added a new job field called “age”, which presents the age of the job using relative, human-friendly terms. Examples include, “5 days ago,” “Yesterday,” “12 hours ago,” and “just now.”

While showing it on your site will require a developer to customize your job info bar or manually include it elsewhere, you can nicely replace a job posted/published date with a relative term that might grab your users attention better.

For example, “Posted: 2/16/2020” might easily be ignored by a user, but “Posted: 2 Hours Ago” could inspire haste because the user feels like they can get ahead of others in this new opportunity.

Updates to Application and Processing

The following updates expand and improve applications and application processing:

  • Improved duplicate prevention. One bug fix and three additions were made to reduce some of the false negatives our users encountered, which should hopefully further reduce duplicates for all users.
  • Added Occupation and Company as available fields to the form for all users.

Increased Frequency of Bullhorn Communications

Matador Jobs will now communicate with Bullhorn once per 10 minutes, but each type of communication is more segmented moving forward. For example, instead of one hourly “sync everything” call, as in 3.6.0, there will be a “sync jobs” call and then ten minutes later a “sync applications” call, etc. The net result is more prompt communications with Bullhorn, broken up into smaller chunks.

Several Maintenance Tools for Admins Added

One of our goals with making Matador Jobs was to simplify the difficult task of communicating with Bullhorn APIs simple. So, as we help it grow, we seek more and more opportunities to add tools and features to further this goal.

  • Added a “Hard Sync” to Matador Settings. This will force all jobs to update, instead of skipping updates if the existing job was not updated or republished in Bullhorn since the last sync. It was previously only a possible to override caching via the single “Sync This Job” button.
  • Added the ability to recount taxonomy terms. This will help admins fix issues where Categories or Locations are not showing properly on the site.
  • Added a button to delete all successfully synced applications (for users who do not have this done automatically).
  • Added four automatic routines that Matador will run from once per load to once per day to monitor the health of the website and the Matador Jobs connection. If these routines find a problem, one or the following things may occur: automatic maintenance, on-screen notices, and/or alert emails.
  • You may now define your Bullhorn credentials in WordPress configuration files, hiding these sensitive details and improving your overall security.

Simplified Extension Development

While this won’t be exciting to most of our users, we also did substantial work improving the tools that we use to develop Matador Jobs Extensions. These will help developers more quickly and efficiently build extensions to add features to the Matador Jobs.

These updates enabled the Matador Software team to prepare the release of two new All-Access Extensions that are releasing alongside 3.7.0, with two more coming in the following weeks.

These two new extensions are available for download to subscribers of an All-Access subscription beginning Monday, February 22:

  • Matador Jobs Pro – DaXtra Extension
  • Matador Jobs Pro – Contact Forms

And So Much More!

Matador Jobs 3.7.0 includes over 300 developer commits with more than 60 bugfixes and new features, and several improvements to internationalization.

Matador Jobs has been tested and supports PHP versions 5.6 to 7.4 and WordPress versions 4.7 to 5.6, though we strongly recommend users always run the most up-to-date PHP and WordPress versions available to them.

We highly recommend our users install updates first onto a staging or development environment to ensure there are no conflicts with your theme, other plugins, or server environment before updating your main website.

Matador Jobs 3.7.0 will be released for automatic update to subscribers on Thursday, February 18th. If your subscription is expired, renew it on your account page. Subscribers who would like an advance copy of Matador Jobs 3.7.0 prior to Thursday 2/18 can request a copy via our support form.

Get More Social Engagement And More Applications by Removing Social Sharing Links on Jobs

Since the early days of the internet, anybody who puts something on the internet wants to have it rebroadcast everywhere possible. Long ago that was to sites like Digg and Newsvine (RIP) and niche message boards and as of late that is to social media sites like Facebook and Twitter, but regardless of when we were sharing, there was almost always a “share” button to make it easier.

So where are those “share” buttons on our jobs?

While Matador Jobs is known and designed to be nearly infinitely customizable, we purposely chose to omit social sharing tools on the jobs. This is one of the few ways we’ve ever truly pushed our thumb on the scale to influence our users. We believe that your business will be better without social sharing links and it boils down to two key reasons:

  1. Job Seekers Don’t Share Jobs, and,
  2. Recruiters Should Share Jobs “On Purpose”

Let me break those down.

Job Seekers Don’t Share Jobs

Early in Matador Job’s lifespan, we had the fortunate luck of working with an agency user who had hired a User Experience/User Interface expert to help them improve their site.

The UI/UX expert had a few changes for him that were on us at Matador to help with. We took this advice and pushed it beyond just that one client’s site.

Today, we still reference that free insight from that skilled expert on User behavior. Though that insight is getting a little dated, if you’ve ever talked to us on the phone or a video call, you probably have heard us talk about one of the key points from that insightful feed. It was, and still is valuable insight.

One of those insights was this: job seekers won’t share jobs.

It makes sense, if you think about. Why would a random job seeker happen upon a job board site, see a job they think is great, and put it on their Facebook profile for their Uncle Joe to see? I mean, why would they even share it on a professional social network like LinkedIn when doing so could increase the competition they face in landing that role for themselves?

A second related insight was: don’t distract the user.

So why not just keep the buttons, even if they don’t get engagement? Well, those “share” buttons are distractions that could result in the user (applicant) not doing what we want them to do (applying).

Good UI/UX promotes simple, distraction-free design in order to illicit the desired response from the user. The social sharing buttons could potentially distract an applicant from completing their application at all.

So, not only do job seekers not share jobs, but the presence of sharing tools could make it less likely for them to even apply!

Recruiters Should Share Jobs on Purpose

“But Jeremy,” you interject, “I need the buttons so my recruiters can easily promote jobs on social media!”

I hear you, and my response is: if they want or need to share the jobs on social media, they should put more effort into it than just clicking a “share” button!

Social sharing tools, including the one we started but removed from Matador Jobs all those years ago, provide a “draft” social post that usually has some generic placeholder words. They might be something like:

“Check out this #job I just saw on ABC Jobs!”

That’s pretty unhelpful, right? What makes it worth my time to visit? If I scrolled down to that social post about a job, why would I be compelled to click the link? Answers are: yes, its not helpful, no its not worth my time, and no, I am not compelled to click that link.

If your recruiters use social media to share roles, they should be doing it “on purpose“. They can do this in two ways, starting with writing a great post. Take this one for example:

“Fantastic opportunity for an accountant with at least 5 years of experience to join a prestigious company and work in the incredible FiDi of San Francisco; the financial center of the west coast. Enjoy great pay and benefits, and take advantage of incredible career advancement opportunities. See more here…”

Imagine I’m an accountant with 5 years of experience and I live in or want to live in the Bay Area of California… you just got my attention! And it has great pay and benefits and opportunities for advancement? Hmm. I might just need to click on that link!

The second way your recruiters can share “on purpose” is to use a campaign link building tool to track user engagement with their posts.

So many of our users don’t realized that if you append campaign tracking variables to your job links, the values you include in the variables can result in the “source” value in the Bullhorn Candidate (for new candidates) and Bullhorn Submission (for all applications) will have that info.

So let’s say I am writing three social posts for LinkedIn for the same job. Each post focuses on a specific aspect of the role, and I add utm_campaign=Mar1Social1 to one job link and utm_campaign=Mar1Social2 to the end of another. When a person applies after clicking on the second link, your “source” will say this: ABC Jobs (Social/LinkedIn/Mar1Social2).

With this information, you learned that the second of the three social posts grabbed the most attention from your audience! Now next time you share a job posting, you might make your post most like your 2nd one that day.

We use this campaign link builder tool, but there are lots out there to help you with this, including some popular WordPress plugins.

Wait, What About Refer-a-friend Programs?

A third use case for social sharing tools we occasionally hear is related to refer-a-friend programs. These are where an employee will tell their friends about their job and, if a friend gets hired, they referring employee gets a bonus.

Generally, this is an uncommon use case for Matador Jobs since we commonly work with agencies as opposed to direct hiring companies, but when a direct hiring company uses Matador Jobs and they need social sharing for a refer-a-friend program, fear not.

Because Matador Jobs job posts are simply WordPress posts, any WordPress plugin that adds social sharing buttons to a custom post type can be added to your site to add social sharing buttons to your jobs.

That said, in order to prevent applicants from becoming distracted as we previously explained, we do advise our users make a special page for internal users only to house social sharing buttons for this purpose.

So, Skip the Social Sharing Buttons

So, get the best results out of your Matador Jobs powered job board and skip the social sharing links! Keep your applicants focused, and teach your recruiters to post to social networks on purpose, and you will have fantastic results!

Announcing Matador Jobs Pro All Access Extension: DaXtra

Today, February 22, 2021 we release version 1.0.0 of our newest Matador Jobs Pro All-Access Extension: DaXtra. It is available for immediate download by our All-Access Subscribers on its extension page (requires a logged in user to see download button).

What is DaXtra Technologies?

DaXtra Technologies is another Bullhorn Marketplace Partner like Matador Jobs and they provide a number of extremely powerful tools to help recruiting agencies and HR departments find and place talent. Their tools include three that we’ve been able to integrate onto Matador Jobs powered job board marketing sites. They are:

  • DaXtra Apply
  • DaXtra Match
  • DaXtra Capture

In order to use this Extension, active subscriptions in the various DaXtra services is required. Good news though, you can pick-and-choose which features you need; use one or all!

Extension Features

The key features of the extension are:

  • Replace the Matador resume upload with a new resume upload that accepts inputs from not only the local device, but also Microsoft OneDrive, Google Drive, and Dropbox. This will improve response rates from mobile device users. (Requires DaXtra Apply)
  • Submitted resumes are parsed and the application form is automatically filled out with data from the parsed resume. This is excellent for sites with longer application forms! (Requires DaXtra Apply)
  • Either via an application form or widget/shortcode, once a user has parsed as resume, they can get recommendations for other jobs based on their resume! (Requires DaXtra Apply & DaXtra Match)
  • Instead of directly submitted applications to Bullhorn, submit them to DaXtra Capture for advanced parsing and AI-based processing to create Applicant data with more detail than ever before (Requires DaXtra Capture)

Learn more about the features with this helpful video!

Matador Jobs Pro DaXtra Extension Features

Get It Now!

Matador Jobs Pro DaXtra Extension is ready for download and installation now! Visit its extension page for more information and to download (log in to see download button).

Matador Jobs Pro DaXtra Extension has been tested and supports PHP versions 7.1 to 7.4 and WordPress versions 5.4 to 5.6, though we strongly recommend users always run the most up-to-date PHP and WordPress versions available to them. DaXtra features require active subscriptions with DaXtra Technologies.

Matador Jobs Pro DaXtra Extension requires an All-Access level subscription. If you don’t have a subscription, sign up now, or if you need to upgrade, you can do so on your account page. If you’d like a demo of Matador Jobs Pro or the DaXtra extension, request a demo. If you find any issues or need help setting it up, contact us via our support form.

Matador Jobs 3.7.1

Today, Monday, February 22, 2021, Matador Jobs 3.7.1 released with three bugfixes discovered following the release of 3.7.1 last week.

3.7.1 Bugfixes

3.7.0 had two “beta” versions and two “release candidate” pre-release versions distributed to more than ten hand-selected users of Matador Jobs to help us find any outstanding issues prior to final release. Despite that, a few issues slipped by our quality control. Over the first weekend of 3.7.1, two were found and fixed following user feedback:

  • We found a bug that caused applications to sync to Bullhorn slowly. Users who got more than about 72 applications per day (or more than three per hour, on average) would begin to see backlogs build up. We fixed the bug and now Matador should be able to keep up with an exponentially greater volume of applications.
  • The new setting to disable Matador Jobs stylesheets contained a “default” value that was invalid. This meant that our users could accidentally disable Matador stylesheets upon a settings save following a 3.7.0 upgrade. Since a majority of Matador Jobs users rely on our default stylesheets, this caused some display issues on those sites. This has been fixed so it won’t happen in the future.

A third, previously identified lower-priority bug was also fixed during this work, as the settings-related bug fix involved work in the same area of the code.

Update Now!

Matador Jobs 3.7.1 is released for automatic update to all subscribers as of today, Monday, February 22, 2021. If your subscription is expired, renew it on your account page. If you find any issues, please send a support request.

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 https://your-site.com/jobs and a job URL that follows the pattern like https://your-site.com/jobs/a-sample-job-page, 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 https://your-side.com/jobs/1234 for Bullhorn job ID 1234 will automatically redirect to the job page at https://your-site.com/jobs/a-sample-job-page 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.

Features

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.

Bugfixes

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:

https://your-site.com/jobs/the-name-of-the-job-with-dashes

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

https://your-site.com/jobs/{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.

Features

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.

Bugfixes

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.

Bugfixes

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:

https://thenewstack.io/words-matter-finally-tech-looks-at-removing-exclusionary-language/

https://www.duncannisbet.co.uk/removing-harmful-language-from-my-lexicon