How are conflicts handled if my MLS has custom fields or unique rules that differ from standard RESO fields?

Conflicts between your MLS’s custom fields and standard RESO fields are handled in the mapping layer. You decide exactly what comes into WordPress and how it behaves there. MLSimport shows all fields from your MLS feed, lets you map custom ones or skip them, and blocks unmapped or private data from breaking sync or the front end. In practice, RESO stays clean, your local rules stay intact, and listing updates keep running on time.

How does MLSImport treat custom MLS fields that are not in RESO?

Custom MLS fields can be brought in or ignored, and listing sync still stays stable.

The plugin reads your MLS feed, lists every field, and then lets you decide what to do with each. MLSimport shows both standard RESO fields and extra board-specific fields, which can reach 100 or more per MLS. You can enable a custom field, give it a clear label, and store it as a WordPress custom field on each property.

When you open the MLSimport field mapping screen, you can mark any custom field as “import” or “ignore.” Imported fields are saved as post meta and are ready for themes, search forms, or templates. Ignored fields never touch your database, which keeps the site lean and cuts noise in the admin area. At first this seems limiting. It isn’t.

Unmapped custom fields are skipped safely, so sync jobs don’t fail when your MLS adds or changes something odd. The plugin just passes over unknown or unused fields and finishes the job on schedule, hourly or on another interval you pick. That behavior keeps listing creation and updates steady even when your MLS structure shifts more often than RESO specs expect.

The table shows each field either becomes a clear WordPress data point or is skipped cleanly. You keep control over which custom items matter while MLSimport keeps a steady, predictable sync process in the background.

What happens when my MLS rules conflict with standard RESO display or behavior?

Conflicting MLS display rules are handled using private fields plus conditional front end templates.

Some boards demand certain text or fields show in exact ways, even when RESO keeps a simpler shared model. MLSimport pulls everything in, then lets you control display at the theme level so you can match those local rules. Required items like attribution lines, listing brokerage, and “last updated” timestamps can be wired into your page templates and always kept visible.

For fields your rules treat as sensitive, like agent only remarks or showing notes, the plugin can store them as private meta. That means they sit in the database while your theme templates never show them to visitors. You still see them in the admin when editing the property, which helps with office workflows, while staying inside MLS policy. It sounds fussy, but this is usually where compliance trouble starts.

Per board rules about hiding addresses, unit numbers, or prices can live in template conditions. MLSimport supplies the raw value, and you add checks like “only show street number if ‘DisplayAddress’ is true.” Since sync jobs often run about once an hour, time sensitive fields stay fresh enough to meet “prompt update” rules. Manual edits stay rare, which is the real time saver.

How does MLSImport map unique fields into WordPress themes and searches?

Unique MLS data points can turn into searchable filters or badges in many real estate themes.

At mapping time, you can rename fields to match words you actually use on the site. For example, “WaterfrontYN” can become “Waterfront” or “Waterfront Description.” MLSimport then writes that value into the custom field slot your theme expects. In many real estate themes, including ones that support ACF(Advanced Custom Fields), these fields appear in template builders.

Once the data lands in the theme’s custom fields or ACF groups, you can connect it to search forms. Many supported themes read those fields and let you add dropdowns, checkboxes, or sliders without code. Location fields like city, county, and property type often map into WordPress taxonomies. So archive pages and URL structures line up with your market, and narrow pages like “Condos in Zip 94110” are easier to build.

• You can rename incoming MLS fields so labels match your site language.
• Extra custom fields can drive badges like “Waterfront” or “Horse Property.”
• Theme taxonomies receive mapped locations and power city and neighborhood archives.
• Search bars can expose any mapped field as a filter in supported themes.

Because MLSimport only pushes values into fields you picked during mapping, your search and badge logic stays predictable. If a board later adds a new field, nothing breaks. You just decide if that field becomes a filter, a detail line, or isn’t used at all, and you can change your mind later without starting over.

Can I add my own fields or calculations without breaking MLSImport updates?

Custom analyst fields sit beside MLS data because sync only touches mapped fields.

You can create your own numbers like cap rate, “Investment Score,” or renovation budget and save them as custom fields. MLSimport doesn’t track those fields, so the sync job leaves them alone on every run. That lets you mix raw MLS feed data with your own insight without worrying that the next sync wipes your work.

If your theme spots ACF fields automatically, those new values can show in layouts and search. You might add a checkbox for “Investor Friendly” or a range field for “Projected Yield,” then wire that into your property template builder. Manual taxonomies like “Luxury,” “Historic,” or “Needs Work” stay separate too, since the plugin only syncs the fields and taxonomies you mapped to the MLS feed.

Only the exact set of mapped keys is updated when MLSimport runs its job, hourly or a few times per day. Status, price, photos, and standard details stay in sync, while your own analytics sit beside them untouched. I should say, this split sometimes feels rigid, but it keeps you compliant with MLS data while still giving you room to build a deeper investing or niche story on each listing.

How does MLSImport handle geocoding and location conflicts between RESO and my MLS?

When coordinates are missing, address fields can pair with geocoding tools so map search still works.

If your MLS already sends latitude and longitude, those values are stored and used by map widgets in your theme. When an MLS only sends addresses, MLSimport still imports street, city, state, and postal code as separate fields. You can then pass those address parts to an outside geocoding add on so each listing ends up with a map point.

City, state, and area names are normalized into the location structure your theme uses. That might mean mapping “Area” into a taxonomy like “Neighborhood.” That structure powers location archives and radius searches in supported themes. As a result, even when RESO’s ideal location fields and your board’s naming don’t fully match, the mapping layer keeps search and maps behaving in a clear way.

FAQ

Do I have to import every custom field from my MLS, or can I pick only a few?

You can import only the custom fields you actually need and ignore the rest.

In the mapping screen, MLSimport lists every field the MLS feed exposes, including custom ones. You decide field by field which to enable, rename, or skip. Unused fields never enter your database, which keeps things clean and avoids clutter in your WordPress admin and templates.

What if two MLS boards use different names for the same concept, like “Area” and “Neighborhood”?

Different MLS field names can be sent into the same WordPress field or taxonomy during mapping.

When you set up each feed, you choose where “Area,” “Neighborhood,” or a similar field lands in WordPress. MLSimport lets you point both boards’ fields into the same target, so your theme sees one clean “Neighborhood” concept. That way, searches and archives stay consistent even when the MLS labels don’t agree.

Will changing my WordPress theme break existing field mappings or imported data?

Switching themes doesn’t erase imported data, but you may need to hook fields into new layouts.

The data that MLSimport stored lives in your WordPress database as custom fields and taxonomies, which stay in place. What usually changes is how the new theme reads and shows those fields in templates and searches. You may spend time re pointing key fields to the new theme’s layout builder, but the raw listing content remains intact.

How fast do syncs run, and how quickly do MLS rule or field changes show on my site?

Syncs usually run on a set schedule, and rule or field changes appear after the next job.

You choose a cron schedule for MLSimport, with hourly or every few hours being common for many sites. When your MLS changes a rule or adds a field, the plugin picks up the new structure on the next job and exposes new fields in the mapping UI. Display changes tied to those fields go live once you map them and update your theme templates. Sometimes that delay feels slow, but it keeps servers from being hammered nonstop.