Teaching WordPress What a Job Is

Jobs were importing, and the board immediately needed what every listings site needs, ways to slice, by department, by job type, by location. In WordPress those slices are taxonomies attached to the post type, and this post is that structure as built, including the small flags whose absence made my taxonomies half-invisible and taught me to read register_taxonomy’s arguments properly.

Three taxonomies cover how people actually browse jobs:

function jab_register_taxonomies() {
    $shared = array(
        'public'             => true,
        'show_ui'            => true,
        'show_admin_column'  => true,
        'show_in_quick_edit' => true,
        'hierarchical'       => true,
    );
    register_taxonomy('jab_department', 'jab_job',
        $shared + array('labels' => array('name' => 'Departments')));
    register_taxonomy('jab_jobtype', 'jab_job',
        $shared + array('labels' => array('name' => 'Job Types')));
    register_taxonomy('jab_location', 'jab_job',
        $shared + array('labels' => array('name' => 'Locations')));
}
add_action('init', 'jab_register_taxonomies');

The shared flags are the evening I lost, condensed. My first registration passed only labels and hierarchical, and the taxonomies technically existed while being useless, terms would not save from the editor, no columns showed in the jobs list, quick edit ignored them. Each symptom was a missing flag, show_ui puts the taxonomy boxes in the editor at all, show_admin_column adds the sortable columns to the jobs list so you can see at a glance which jobs have terms, and show_in_quick_edit makes bulk cleanup humane. Taxonomy registration defaults are conservative, and a taxonomy is only as real as the flags you grant it.

The importer assigns terms as jobs arrive, mapping API fields to taxonomies and creating terms on first sight:

wp_set_object_terms($post_id, $item['DepartmentName'], 'jab_department');
wp_set_object_terms($post_id, jab_map_schedule($item['PositionSchedule']), 'jab_jobtype');
wp_set_object_terms($post_id, $item['PositionLocationDisplay'], 'jab_location');

wp_set_object_terms creates missing terms automatically, so the taxonomy vocabulary grows organically from real data, no pre-seeding lists of departments that may never appear. One honest note from later in the project, filtering by location eventually moved to meta LIKE matching rather than exact term matching, because location strings from the source vary, City, State against City, ST, and exact term filters miss what substring matching catches, taxonomies stayed the browse structure while search got the forgiving path. Structure for browsing, forgiveness for searching, both fed by the same import.

A few things people ask me about this

Why do my taxonomy terms not save from the post editor? Usually missing registration flags, show_ui and friends. Register with public, show_ui, and check the editor again, the boxes and saving appear with the flags.

Should filters use taxonomy queries or meta queries? Taxonomies for clean browse facets, meta LIKE for user-typed searches where source strings vary. The job board uses both, each where its strictness fits.

Next

The jobs had homes and labels, but their bodies were stubs, because my first fetch asked the API for minimal fields. Getting the full announcements, duties, qualifications, benefits, is the next post.