Your Job Search system works because three things are aligned:
The form sends filters as URL parameters (GET)
The SearchQuery widget reads those parameters and builds SQL
The SQL matches how the data is stored in the database (data_posts columns vs users_meta keys)
If any of those three do not match, the filter will silently fail.
Brilliant Directories has two common storage models for posts:
These live in the data_posts table.
Examples include jobs, events, coupons, articles, and most standard post types.
They use variables like:
post_title
post_content
post_category
post_price
post_start_date
post_image
These live in users_portafolio_groups (BD sometimes labels these as portfolio groups).
Examples often include:
Classifieds
Properties
Products
Photo Albums
Digital Products
They use variables like:
group_name
group_desc
group_category
group_location
Important: Your existing Job SearchQuery is written for Model 1, the data_posts world. If you duplicate to a multi image post type, you must rewrite the table and field references.
Before you do anything else, identify which model your target post type uses.
You already have 3 widget parts for the Job Search widget:
JobSearchWidget.html
JobSearchWidget.css
JobSearchWidget.js
Your goal is to copy these into a new widget for your new search page.
In BD Admin:
Go to the page where you want the new search widget to appear
Add an HTML widget (or duplicate the existing widget if BD lets you)
Create 3 code sections exactly like your job widget:
HTML box: form and UI markup
CSS box: styles
JS box: slider and selectpicker behavior
Name them something like:
EventSearchWidget.html
EventSearchWidget.css
EventSearchWidget.js
The naming is for you, BD does not care about the filename, it cares about the code and the widget location.
Paste the JobSearchWidget.html into your new widget HTML box.
Now identify these parts:
You will see something like:
method=“get”
id=“jobSearchForm”
action=”/”
What it does:
method GET means inputs become URL parameters
action using $dc[‘data_filename’] means it submits to the current data category page automatically
What to change:
Change the form id to match the new widget, only for clarity
Example: eventSearchForm
Keep method get
Keep action using $dc[‘data_filename’] if this widget lives on the correct search results page for the feature
This is the contract between the form and the SearchQuery.
Example:
name=“q”
name=“category[]”
name=“security_clearance[]”
name=“price”
What to change:
You must decide which filters you want in the new search
For each filter you keep, you must keep the same input name that your new SearchQuery will read
If you rename a filter input, you must also rename the GET check in the SearchQuery
If you do not do both, it will not work.
Paste JobSearchWidget.css into the new widget CSS box.
What to change:
Typically nothing required unless you want a different look
If you changed class names in HTML, update CSS selectors to match
Paste JobSearchWidget.js into the new widget JS box.
Important: this JS relies on:
jQuery being present (BD has it)
selectpicker being present (Bootstrap select plugin)
rangeSlider libraries being loaded via the CDN links you included
What to change:
If your slider input class changes, update the selector:
$(”.jobs_slider”) might become $(”.events_slider”)
If your hidden input name changes, update the line that sets:
$(’#price’).val(min + ‘;’ + max);
Pro tip:
If you are not changing the salary slider, you can keep it exactly as is.
This is the core engine.
You have:
Search_JobPost_SearchQuery.html
You will create a new SearchQuery widget for the new post type.
In BD Admin:
Go to the feature page for the new post type search results
Find the SearchQuery widget that controls results
Duplicate your job SearchQuery into a new SearchQuery widget, or replace the existing one carefully
Name it something like:
Search_EventPost_SearchQuery.html
This is where your post storage model decision matters.
Your FROM stays like:
data_posts dp
users_data ud
subscription_types st
Your joins and base conditions stay very similar.
Your FROM changes to:
Then you need to check how BD expects to join user tables for that feature.
The concept stays the same:
Connect the post record to the user record
Only show active users and live content
Filter by the correct data category
The exact join column names differ, so when you do a first pass, use the debug method below to inspect what BD normally uses for that feature.
Now we do the most important part: mapping each filter to where the data actually lives.
Every filter is stored in one of two places:
A real column on the post table (data_posts or users_portafolio_groups)
A users_meta key value record linked to the post id
Use this checklist.
Common examples in standard posts:
title
content
category
price
start date
location fields
latitude longitude
In SQL, these are like:
dp.post_title
dp.post_content
dp.post_category
dp.post_price
Anything created as a custom field in the form builder often ends up in users_meta.
Examples from your job search:
security_clearance
position_type
drug_tested_position
These require EXISTS subqueries that check:
database_id equals the post id
key equals the field key
value equals the selected option
If your HTML has:
Your SearchQuery must check:
Then create SQL that uses those values.
If you change the HTML input name to:
Then your SQL must check:
This is the most common duplication failure.
This is the second most common failure.
The meta key is not the label the user sees.
It is the internal field key.
Example:
Your dropdown label might say:
But the meta key might be:
If you use the wrong key in SQL, it will never match anything.
Where to get the correct key:
In BD, open the form builder for that post type and inspect the field key
Or look at how the existing feature SearchQuery filters it
Or inspect the database by locating the post id and checking users_meta rows tied to it
This is how you test and confirm everything is wired correctly.
On the search page:
Select filters
Click Search
Look at the URL
You should see things like:
?q=nurse
&category[]=12
&position_type[]=remote
If you do not see a parameter, the form is not sending it.
Fix:
Ensure the input has a name attribute
Ensure it is inside the form
Ensure it is not disabled
Your job SearchQuery already echoes the SQL.
Do the same in your new SearchQuery:
temporarily echo the final SQL string so you can see it
if you only want admin to see it, wrap it in a condition for your user id
What you are checking:
Does the SQL include the WHERE clause for the filter you selected
Does the SQL include the correct field name and correct meta key
If the clause is missing:
If the clause is present but results are wrong:
The storage location is wrong (column vs meta)
The values do not match what is stored
Case sensitivity issues
Here is the practical list.
Optional, for clarity only.
Example: jobSearchForm to eventSearchForm
Required.
These must match whatever your SearchQuery reads from $_GET.
This is your form to SQL contract.
Required if you switch post types.
Standard posts:
dp.post_title
dp.post_content
dp.post_category
dp.post_price
Group based posts:
pg.group_name
pg.group_desc
pg.group_category
Required if the new feature uses different field keys.
Example:
job meta key might be security_clearance
event meta key might be event_type
You must update:
Often required.
Your current job SearchQuery includes checks tied to:
dp.data_id
dp.data_type
subscription data_category access logic
When duplicating to another feature, you must make sure:
It is filtering the correct data category
It is not accidentally still filtering jobs
If you are using $dc context variables, keep them.
If you hardcoded job data ids, remove them and use $dc variables.
Here is what happens when a user searches.
User selects filters in your HTML form
Browser submits the form as a GET request
BD loads the results page for that feature
BD runs the SearchQuery widget code
Your SearchQuery reads $_GET values
Your SearchQuery builds a SQL query string
BD executes that SQL and returns matching post ids
BD loads each post and renders the results list
Where the data is stored:
core post fields live in the post table
custom fields often live in users_meta
So your SearchQuery either:
filters directly on the post table columns
or filters via EXISTS subqueries on users_meta
Use this every time.
Pick target feature and confirm storage model:
Duplicate the HTML widget:
update form id
update filter fields
confirm all inputs have correct name attributes
Duplicate CSS and JS:
Duplicate the SearchQuery widget:
update base FROM table and aliases if needed
update field names (post_ vs group_)
update meta keys to match the new feature
Test URL parameters:
Echo SQL:
Validate field storage:
if filter uses meta, confirm users_meta has that key for a known post id
if filter uses column, confirm the column exists and has the right values
Tell me which post type you are duplicating this to.
Example answers:
Events
Classifieds
Properties
Products
Then I will do the next step with you and give you a concrete mapping table like:
Filter label
Form input name
GET parameter
Database storage location (column or meta)
Exact SQL block to paste
And I will also tell you exactly which parts of your current Job SearchQuery you can keep as is, and which lines must change.