Job regions as dropdown IS possible

Hi, I would be extremely interested to know how you did that.
Can you share the exact markup you added for this? Thanks a billion in advance

Hi jobme,

here we go with some code:

filename: job-filters.php

<?php
/**
 *
 */

$s_categories 	= get_option( 'job_manager_enable_categories' ) && get_terms( 'job_listing_category' );
$s_regions 		= get_terms( 'job_listing_region' );
wp_enqueue_script( 'wp-job-manager-ajax-filters' );
?>

<form class="job_filters">

	<div class="search_jobs">
		<div class="row">
			<?php do_action( 'job_manager_job_filters_search_jobs_start', $atts ); ?>

			<div class="<?php echo $s_categories ? 'col-md-6 col-sm-6' : 'col-md-12 col-sm-12'; ?> col-xs-12 search_location">
				<label for="search_location"><?php _e( 'Location', 'jobify' ); ?></label>

				<div class="has-select">
					<div class="select">
						<select name="search_location" id="search_location">
							<option value="0" selected="selected">Alle regios</option>
							<?php foreach ( $s_regions as $region ) { ?>
							<option value="<?php echo $region->name; ?>"><?php echo $region->name; ?></option>
							<?php } ?>
						</select>
					</div>
				</div>

			</div>

Thanks a lot for sharing this. Now, I noticed exactly what you mention on your other thread about dashes and spaces. I face the exact same problem. BUT the problem is elsewhere.

With the above piece of code, what we achieve is essentially search within the LOCATION of job ads for a term equal to the name of the job REGION. So, it actually searches if there is a location that contains the name of the job region.

That’s why it doesn’t work. Do you have any idea how we can reconfigure the above so it searches within the regions?

The way you adapted the script is basically still using the location search function which is text-based. On the other hand, if we “replicate” the way it searches for the job categories, we ‘re done.

Here is the relative piece of code that we should find a way to “replicate”.

<?php if ( $categories ) : ?>
				<?php foreach ( $categories as $category ) : ?>
					<input type="hidden" name="search_categories[]" value="<?php echo sanitize_title( $category ); ?>" />
				<?php endforeach; ?>
			<?php elseif ( $show_categories && $s_categories && ! is_tax( 'job_listing_category' ) ) : ?>
				<div class="col-md-3 col-sm-12 search_categories">
					<label for="search_categories"><?php _e( 'Category', 'jobify' ); ?></label>
					<?php wp_dropdown_categories( array( 'taxonomy' => 'job_listing_category', 'hierarchical' => 1, 'show_option_all' => __( 'All Job Categories', 'jobify' ), 'name' => 'search_categories', 'orderby' => 'name' ) ); ?>
				</div>
			<?php endif; ?>

			<?php do_action( 'job_manager_job_filters_search_jobs_end', $atts ); ?>

No idea how to do it myself however..

I’m still working on that one. I think that the problem will be in the admin_ajax.php call we do.

At first I thought it maybe had to do something with the call in the ajax and how it serialized the dash. But if you look in the network tab of the inspector the call is right. Now I will work on trying to look for the job_region as you state and not the job_location. But I still think its strange that when I have regions without a dash everything goes fine.

Will get back to you on that one!

I do think I am very close… Looking in the following file now:

wp-job-manager-functions.php (which is in the plugins/job-manager folder):

It is the get_job_listings function that does the actual search. Within this function on line 71 we can finde the following code:

// Location search - search geolocation data and location meta
	if ( $args['search_location'] ) {
		$location_post_ids = array_merge( $wpdb->get_col( $wpdb->prepare( "
		    SELECT DISTINCT post_id FROM {$wpdb->postmeta}
		    WHERE meta_key IN ( 'geolocation_city', 'geolocation_country_long', 'geolocation_country_short', 'geolocation_formatted_address', 'geolocation_state_long', 'geolocation_state_short', 'geolocation_street', 'geolocation_zipcode', '_job_location' )
		    AND meta_value LIKE '%%%s%%'
		", $args['search_location'] ) ), array( 0 ) );
	} else {
		$location_post_ids = array();
	}

I think this is where the actual matching of form input (search_location) and database job posts is done. I don’t know yet how to alter the query/code without breaking the whole search widget. Next on my todo is adding a variable search_region to the query. That way we can change the form input to search_region for the frontend and still keep the search_location option intact if we wanted to use it for the future. Will keep you posted on the progress of this one. Its a tricky one… ??

From what I can understand you are on the right track for this and keeping the location intact is very wise to do.

Please do let me know if you find out anything. I’m working on it myself and keep you updated too.

Thanks

If I read the query well (not that good in SQL) it matches the search_location to either the:

‘geolocation_city’,
‘geolocation_country_long’,
‘geolocation_country_short’,
‘geolocation_formatted_address’,
‘geolocation_state_long’,
‘geolocation_state_short’,
‘geolocation_street’,
‘geolocation_zipcode’,
‘_job_location’

I think thats why we can’t find regions with dashes. If you look at the geolocation_state_long in the CMS what will be matched is the english version of the state with a space as stated in the google api, or whatever api is used to get those geo-locations. So it matches the search_location input to this info in the db not the actual job_region.

I think the developer of Predefined Regions needs to rewrite this and make an actual relation between the joblisting post and the region, not just match the geo/job_location and the search_location.

Ok got the right way in SQL to determine the posts that match the search_filter:

SELECT DISTINCT term_id FROM {wpdb->terms}
WHERE slug LIKE 'search_region' -> gets you the job_region id

With that job_region id you can get the post_id’s like this:

SELECT DISTINCT object_id FROM {wpdb->term_relationships}
WHERE term_taxonomy_id = 'job_region_id' -> gets post id's

The only thing we have to do now is to select all the posts from the posts db like this:

SELECT DISTINCT * FROM {wpdb->posts}
WHERE ID = 'post_id'

As I stated earlier my SQL isn’t that good. So these queries are all separated and needs to be altered to do these 3 steps in one query. The last query gets only 1 post out of the posts table. This isn’t right either it needs to get all the posts that match the post_id’s from the second query.

We need to merge these three queries in one big one that outputs all the posts that match the search_region! Hope a SQL guru sees this and want to helps out a bit for this one!

Query update!!!!

SELECT DISTINCT * FROM wp_posts
		    WHERE ID IN (
		    	SELECT DISTINCT object_id FROM wp_term_relationships
		    	WHERE term_taxonomy_id IN(
				SELECT DISTINCT term_id FROM wp_terms
				    WHERE slug LIKE [search_region]
				)
			)
			AND post_status = 'publish'

This gives you the job_listings that comply to the search_region. I will alter the job-manager-functions.php and the plugin to add this functionality. When i’m done i will post this one!

Ok I did it!!!!

I’ve altered the job-manager plugin so you can filter for job_regions now! I will upload this too github in a day or two!

—– UPDATE ——

Modified files are:

// form markup for ajax values
job-filters.php

// line 89 for non-compressed js
plugins/wp-job-manager/wp-job-manager.php

// various additions
plugins/wp-job-manager/wp-job-manager-functions.php
plugins/wp-job-manager/includes/class-wp-job-manager-ajax.php
plugins/wp-job-manager/assets/js/ajax-filters.js

So turns out this is mainly an alteration of the job-manager plugin not the predefined regions, although there is some effect because of the relation in the query and tables…

Will update it to github soon!

Update! Check it out!

https://github.com/mrpharderwijk/wp-job-manager-regions-dropdown

I hope you as much fun with it as I do now ;)!!!!

Fantastic work mate! Works great now. I admire the way you fixed this in so little time, whereas the developers just said “not possible”.

I noticed one bump that I think would be bad for you as well as me. Spaces still don’t work but also non-english characters don’t bring any results. Do you have any idea if we have to somehow add a charset or something?

Spaces are fixable, I think. Non-english characters will be a little bit more difficult I guess. Can you provide me the payload you send to the admin-ajax and the input in the database?

Hmmm.. not sure what payload sent to the admin-ajax is.
How can I find that out?