Skip to content
W3Bullhorn
W3Bullhorn
Book a demo

Advanced Custom Fields

get_field() answers with Bullhorn data

If your theme already reads fields with ACF, it carries on doing exactly that. Map a Bullhorn field to a name and <code>get_field( 'salary_from' )</code> returns the role’s value — without that value being copied into your database, and without a template change.

Nothing is attached when ACF is absent, or when the map is empty.

What it is

Nothing is mirrored into your database

The obvious way to do this is to copy every mapped Bullhorn field into post meta on each sync. We do not, for two reasons: a job has a hard ceiling on how many meta rows it may carry, and a mirror has to be kept in step with every sync for the rest of the site’s life.

Instead the value is supplied at the moment ACF asks for it, before ACF reads post meta at all. A <code>get_field()</code> call costs one lookup in the map and one read through the same surface the job page itself uses. There is no second copy of your job data to drift, to bloat the database, or to go stale.

Resolution

What it will and will not answer

In this order, which is worth reading if you maintain the theme.

  • A name that is not in the map. Untouched. ACF behaves exactly as it did, so your existing fields are unaffected.
  • A mapped name on something that is not a job. Untouched. A page, a post or a product keeps its own value.
  • A mapped name on a job the visitor may not see. Untouched, so ACF finds no value — the same access check the Elementor layer uses, so a draft or protected role cannot leak through a template.
  • A mapped name on a job the visitor may see. The real value, or an empty string when the role has none.

That last point is deliberate and worth stating plainly: an empty value does <strong>not</strong> fall back to post meta. If an editor once typed something into a field of that name, it must not outlive the real value being cleared in Bullhorn.

On the job edit screen

Visible to an editor, read-only, and writes are refused

The mapped values appear on the job’s edit screen so an administrator can see what the page will show. They cannot be edited there. ACF would still try to save those fields when the job is updated, so the integration reports a mapped field as already handled and nothing is written. Bullhorn is the source: the next sync would overwrite an edit anyway, and an edit that stuck for a few minutes before vanishing is worse than one that was never accepted.

  • Mapped values shown on the job edit screen
  • Read-only, with writes refused rather than silently lost
  • No value copied into post meta at any point
  • Nothing attached at all when ACF is not active

FAQ

Questions about ACF

Short answers here. Anything else, ask us directly.

Will our existing ACF fields still work?

Yes. A field name that is not in the map is not touched, so everything you already have behaves exactly as before.

Do we need ACF Pro?

The integration asks ACF for values through its standard field API. Bring your setup to a demo and we will confirm against the version you run.

Does this add rows to the database?

No. That is the point of it. Values are supplied when ACF asks, not stored.

Can an editor correct a value on the job screen?

No, and that is deliberate. Bullhorn owns those fields, so the correction belongs there — otherwise the next sync quietly undoes it.

What happens if we deactivate ACF?

Nothing attaches and nothing breaks. Your job pages are rendered by the plugin, not by ACF.

Will it work with my existing WordPress site?

That is the design: it installs as a plugin, and job pages are built from your own theme, so the board looks like the rest of your site.

Put your Bullhorn jobs on your own website

See W3Bullhorn working with your own Bullhorn jobs, on a short call with a specialist who knows Bullhorn and WordPress.

Book a demo How it works