FeedSync Companion

Purchase a FeedSync Service license to get the companion sync plugin for the FeedSync service.

1.4.4

• Feature: The “Run Sync” button on the Dashboard now asks for confirmation before starting a manual sync, warning that it’s usually unnecessary (and can be slow) on sites already receiving listing updates in real time via webhook. Uses a dialog styled to match the rest of the plugin instead of a plain browser popup.
• Fix: WordPress Cron (Automatic) no longer also runs a full feed sync on a recurring schedule — it now only auto-processes the queue (uploading and updating images for listings already imported) every 5 minutes, since listing data itself is expected to arrive in real time via webhook. Sites that still need a scheduled feed sync (no webhook configured) can use the “Run Sync” button or their own server cron hitting the sync-feeds endpoint. Existing sites have any leftover scheduled feed sync cleared automatically. The Cron Management settings note was updated to match.
• Fix: A process could be left stuck showing “running” in Process History even though all of its queue work had actually finished. Completion is now correctly deferred only when images were actually queued for background processing, and a listing with a chunked image job in progress (e.g. a large gallery) is no longer counted as “done” while that chunk is still being worked on. Daily maintenance also gained a safety net that closes out any process left stuck at “running” with no outstanding queue items.
• Fix: Using “Delete synced listings” on the Tools page no longer leaves Queue Management full of “(no title)” rows — pending and in-progress queue items (and their process record) for each listing are now cancelled before its post is deleted, so image workers stop trying to process listings that no longer exist. The same cleanup was added to the webhook/feed-driven single-listing delete path, and daily maintenance now also sweeps up any queue items orphaned by a listing deleted another way (e.g. from WordPress’s own Posts list).

1.4.3

• Fix: listing.deleted webhooks now find listings by the composite feedsync_unique_id sent by FeedSync, with the raw CRM unique_id retained as a fallback. The numeric FeedSync database row ID is no longer used for deletion lookups, preventing filtered or deleted listings from being incorrectly reported as already absent while remaining published on the site.

1.4.2

• Fix: A listing deleted in your CRM now takes its photos with it. WordPress detaches a deleted listing’s images rather than deleting them, so every removed listing left its files behind in the uploads folder with nothing to tie them back to the listing they came from — invisible to everything except a full “Sweep upload folders” scan. Any image you uploaded onto the listing by hand in WordPress is still left alone.
• Fix: On the Tools page, “Delete all synced listings” with “Delete associated images” ticked now clears each listing’s images as it goes, while the listing they belong to is still there to find them by. Left unticked, images are kept exactly as before.

1.4.1

• Fix: Site filters (agent, office, listing type and status) were being ignored for anything arriving by webhook, so pushing a listing from FeedSync added it to the site even when its agent was not one of the agents selected for that site. The filters are stored against the site, but a webhook identifies the feed the listing came from — the two are different IDs, so the lookup found nothing, and “no filters set” was taken to mean “allow everything”. A webhook is now matched back to the right site before its filters are applied. Scheduled syncs were never affected.
• Fix: A forced push no longer skips those filters either. Forcing a push means “re-import this listing even though nothing looks changed”, not “ignore whose listing it is” — a force-push of every listing on a feed was adding other agents’ listings to a filtered site.
• Improvement: If a webhook ever cannot be matched to a configured site, that is now written to the log instead of quietly importing everything. Sites syncing more than one FeedSync site should open the plugin’s Settings screen once after updating, which stores the feed-to-site lookup the match relies on.

1.4.0

• Feature: Orphan image scans are now saved as a report you can look through — every file it flagged, why it flagged it, and the identical copy it was matched against — so you can check the list yourself before anything is deleted.
• Feature: Scans can be paused and picked up again. Closing the tab, a dropped connection or a timeout no longer means starting from scratch.
• Feature: Scan just the listings you choose. Paste in listing IDs (image IDs work too) to spot-check them; that scan is saved as its own report and leaves a full site-wide scan untouched.
• Improvement: Reports no longer keep a row for every one-of-a-kind image, so they take far less space on big sites. Those files are still counted, and are still never deleted.
• Improvement: Removed a leftover clean-up button that could delete files without a report behind it, and trimmed database work during a scan.
• Feature: New “Sweep upload folders” mode for the orphan image report. Instead of working outwards from each listing, it reads the monthly upload folders themselves and checks every image against the database, which finds the leftover thumbnails of photos a feed has replaced — files the listing-by-listing scan cannot see, because nothing identical to them is left to match against. Sweep this month, last month, the last 3 or 12 months, one specific month, or every folder.
• Feature: A sweep uses the same saved report, review list and delete pass as the other scans, so you can pause it, come back to it, read through what it found and delete in batches exactly as before. It runs entirely from the Tools page — no command line or WP-CLI access needed.
• Improvement: The sweep leaves anything it cannot be certain about alone. Files touched in the last hour are skipped in case a download is still writing them, and a file whose likely owner is a live image with no sizes on record is listed for you to look at rather than queued for deletion. Every file is re-checked against the database again at the moment of deletion, so anything re-used since the scan is left in place.

1.3.13

• Fix: File renaming issue missing suburb & uniqueID in file name
• Fix: Race conditions adding duplicate images
• Feature: Identify and delete orphan images
• Feature : Cron frequences per minute added

1.3.12

• Fix: 1.3.11 had the new identity fields backwards — the composite feedsync ID was landing in property_unique_id (a real Easy Property Listings field used by its own admin search/sort, an opt-in admin column, REST, and Gravity Forms auto-populate), and the raw CRM uniqueID in the plugin-only property_listing_id. This corrects it: property_unique_id now holds the raw CRM uniqueID as intended, and property_listing_id holds the composite feedsync ID. 1.3.11 was never deployed to a live site, so there is no data to repair — this is a pre-release correction, not a migration. If you’re currently on 1.3.10 or earlier, upgrade directly to 1.3.12 and skip 1.3.11.
• If you have the EPL-core “Unique ID” admin column or search enabled, it will now show the raw CRM uniqueID rather than the composite value, which is the field’s intended purpose.

1.3.11

• Fix: A listing whose agentID changes on the CRM side (e.g. after office reassignment or a feeds:migrate-agent-id reconciliation) is now recognised as an update to the existing WordPress post instead of being imported as a duplicate. The uniqueID portion of the feedsync ID — the one part guaranteed not to change — is now used as a last-resort match when the full ID no longer lines up with anything stored.
• Feature: The raw CRM uniqueID is now also written to its own dedicated property_listing_id field (independent of the composite property_unique_id/feedsync ID), so a listing’s permanent identity is available even if the agentID prefix changes again later.

1.3.10

• Fix: Queue Management action icons (Process, View Log, Delete, Retry) no longer show a broken, misplaced tooltip. A legacy JS tooltip helper in admin.js was running alongside the CSS-based tooltip already used throughout the plugin, injecting a second, unstyled copy at the wrong position on every hover — it has been removed. The remaining CSS tooltip is also no longer clipped on the first row of the queue table.
• Fix: Magic-link pairing no longer fails with “The site name field is required” on sites whose WordPress “Site Title” (Settings → General) is left blank. The companion now falls back to the site’s domain when the title is empty.
• Fix: Removed a PHP 8.4 deprecation notice (“Implicitly marking parameter $request as nullable is deprecated”) from SettingsController::check_permissions().

1.3.9

• Feature: Agent ID (office) filter per site — Settings -> Feeds -> “Agent ID (Office) Filter”. Sync only the listings belonging to specific agency offices, identified by the agentID your CRM sends (ReaXML <agentID>, e.g. 10016383) — the same value stored in the property_office_id field. This is the office, not an individual agent; the existing Agent Username filter continues to select by individual agent, and the two can be combined. Leave it empty and every office is included, as before.
• Feature: The office filter is applied in both directions. Scheduled and manual syncs pass it to the FeedSync API as agent_id, so the filtering happens at the source and only the wanted listings are transferred; incoming webhooks are checked locally against the payload’s property_office_id, so a listing from another office is ignored rather than imported. Several offices are sent as one request instead of one request per office.

1.3.8

• Fix: Image processing no longer repeats indefinitely when a source photo is too large for the host to thumbnail. The attachment’s FeedSync meta (_epl_media_object_id, _epl_source_url, _epl_media_modtime) is now written immediately after the attachment is created, before size generation runs. Previously a request killed inside wp_generate_attachment_metadata() left an untagged attachment that could never be matched again, so every retry re-downloaded the file and created another orphan copy — one per queue run, without end.
• Fix: Size generation is now checked against the available memory before it starts. A source image whose decode-and-resize would exceed the PHP memory limit keeps its full-size file, logs a warning naming the dimensions and the shortfall, and processing continues instead of the request being killed. The estimate accounts for image optimiser plugins (Imagify, ShortPixel, EWWW and similar) that hook wp_generate_attachment_metadata and process the full-size image plus every generated size in the same request, roughly doubling what is needed.
• Fix: A request killed during size generation now records why it died. WordPress’s own fatal handler runs before any plugin shutdown callback and ends in wp_die(), so the diagnosis is captured via wp_php_error_message instead — the log names the PHP error, how long generation survived and the peak memory against the limit, rather than simply stopping mid-run. Each attachment is attempted at most once, so an image that cannot be processed costs a single request instead of every run that follows.
• Fix: Chunked queue items can no longer be retried forever. A resume that makes no progress is charged against the item’s attempt count (reset whenever a chunk does advance), and the item is failed with an explanatory log entry once the retry limit is reached. The generate_sizes queue now also claims its item — previously it never set a processing status, so two workers could process the same item at once — and advances past attachments whose sizes cannot be generated instead of stalling on them or failing the whole item.
• Fix: The Tools “remove duplicate images” cleanup now also finds duplicates that carry no _epl_media_object_id, which is how copies left behind by an interrupted run appear. They are grouped per listing by source image, verified byte-identical (file size and MD5) before removal, and the tagged — or oldest — copy is always kept. The duplicate count shown on the Tools screen includes them.
• Fix: An attachment that was tagged but never received its thumbnails is no longer treated as permanently up to date. It is now handed to the generate_sizes queue, or generated in place when immediate size generation is enabled.
• Feature: Optional HTTPS upgrade for image URLs — Settings → Images → “Upgrade Image URLs to HTTPS”, enabled by default. CRM feeds that mix http and https for the same media library are requested over https at download time only; the API payload keeps the CRM’s original URLs untouched. Hosts that cannot present a valid certificate for their own name (bare IP addresses, localhost, single-label intranet names) are left alone, and a host that cannot serve https falls back to the URL the feed supplied, logging a warning. Also available as the eplfs_https_upgrade_images filter.
• Fix: The http and https forms of the same image URL are now treated as one source. Previously a feed switching scheme would re-download every photo on every listing, and — for images arriving without an original ID — could create a duplicate attachment.

1.3.7

•  Fix: Stale post meta values (such as property_price_display) are now correctly cleared when the CRM explicitly removes the value. Webhook listing updates now extract changes.details.removed and pass it down so the importer deletes the stale keys instead of leaving them untouched.

1.3.6

•  Fix: Batch update webhooks (listing.batch.update) no longer strip percent-encoded characters from URL fields like property_floorplan. The apply_batch_fields() method now detects URL/file-type fields via the EPL meta-box registry and uses filter_var validation instead of sanitize_text_field(), preserving encoded path separators (%2F).

1.3.5

•  Fix: CDN-hosted image URLs containing percent-encoded path separators (%2F) are no longer mangled during storage. Previously esc_url_raw() decoded the encoded slashes which broke external URLs (e.g. S3 floorplan links). Replaced with filter_var validation that preserves the original URL encoding.
•  Fix: Floorplan and other URL meta fields (e.g. property_floorplan) are no longer corrupted by sanitize_text_field() which strips percent-encoded characters. URL/file-type fields detected via the EPL meta-box registry are now validated with filter_var instead, preserving the original encoding.

1.3.4

•  Feature: Update decisions now prefer property_feedsync_mod_time from FeedSync (falling back to property_mod_date when either side lacks it), so internal FeedSync edits — listing edits, status and featured changes — sync to the site even when the CRM’s mod date is unchanged. Both the provider-local value and the new property_feedsync_mod_time_utc (for site-timezone display) are stored as post meta on imports and status-change webhooks. Process lifecycle keys also use the preferred timestamp so distinct internal edits get distinct process records.

1.3.3

•  Fix: Agent sync in “create user + staff” modes no longer creates duplicate staff when the agent’s WordPress user doesn’t exist yet but their directory staff entry does. The importer now always matches an existing staff entry before creating one — by property_staff_username (the stable key linking listings to staff), then email, then post author, and finally by name/slug for legacy entries — attaching the resolved user to the existing staff instead of duplicating it. Ambiguous same-name matches are logged and skipped rather than merged.
•  Feature: Location taxonomy templates — configure, per listing type, what term is stored in the location taxonomy using {field_name} tokens from the API payload (e.g. {property_address_suburb} or {property_address_suburb}-{property_address_state}). Defaults to the suburb (property_address_suburb) when unconfigured, matching previous behaviour.

1.3.2

•  Fix: Listing publish date now updates correctly when property_first_date changes in the feed. The API key property_first_date is mapped to EPL’s property_list_date meta in DataMapper, and the WordPress post_date is re-aligned via a direct DB write so wp_update_post‘s merge behaviour no longer silently preserves the old publish date.

1.3.1

•  Fix: Listing updates now re-align the WordPress publish date when property_first_date changes in the feed. Previously the meta updated but the actual post_date didn’t move; updates no longer overwrite the publish date when property_first_date is unchanged, preserving manual edits.

1.3.0

•  Feature: Inbound webhook delivery audit — listing.batch.update deliveries (e.g. geocode) are now recorded with their source event id, sub-event, originating feed, applied/skipped counts, signature-verification status, source IP and raw payload. Viewable via a “Batch Events” toggle on the Process History page (eye icon opens the raw payload and the listings touched).
• Feature: Per-listing provenance — listings changed by a batch webhook get a webhook:batch:* entry in their history timeline recording where the change came from. Anchors onto the listing’s existing history row / address components (works without property_address_full).
• Fix: Removing an agent in the CRM now clears that agent on the website. The additional agent slots (property_second_agent / _third_ / _fourth_) are derived from the authoritative property_agents list and emptied when an agent is dropped, instead of the stale agent sticking on the listing forever.
• Fix: Onboarding no longer shows the “Migrate Existing Images” step as already complete on a fresh install. The step now only auto-completes once the site has FeedSync-managed listings and none of their images are untagged — previously an empty site (0 images) auto-marked it done before the user had synced anything.

1.2.5

• Fix: Duplicate images are now actively removed on each sync — when multiple attachments share the same original ID, all but the oldest are deleted during the prune pass.
• Fix: Image detection and gallery ordering now consistently resolve to the oldest (canonical) attachment when duplicates exist, preventing mismatched featured images.
• Fix: “Run Update” from the listing metabox now correctly processes the featured image queue item, fixing the wrong featured image being set on manual updates.
• Fix: Overlapping sync runs no longer produce duplicate image queue items — a pending queue item for the same listing and action is updated in place rather than a second row being inserted.
• Fix: Agent sync no longer wipes the property_staff_agent_position field — EPL’s profile_update hook is suppressed during name updates, and position is written to user meta so future profile saves propagate it correctly.
• Fix: Listing publish date is now updated from property_first_date (with property_mod_date fallback) on updates, not just on initial create.

1.2.4

• Fix: Removed EPL licensing message.

1.2.3

• Fix: first date as publish while update.

1.2.2

• Fix: Backfill images incorrect post type fix.

1.2.1

• Fix: Block creation of status multiple status.

1.2.0

• Plugin renamed from epl-fs-companion to feedsync-companion. Manual upgrade required.

1.1.0

• Plugin renamed from epl-fs-companion to feedsync-companion. Manual upgrade required.

1.0.21

• New: Stats to monitor API.

1.0.19

• Feature: Bulk import field mappings by pasting a JSON object instead of adding one at a time.
• Fix: Bulk import feedback message now appears inline instead of at the top of the page.
• Enhancement: FeedSync status dot tooltip now shows last sync time and feed mod date with improved styling.

1.0.18

staff missing meta fixed

Image Processing

Improved image download reliability
Increased the image download timeout to better support slow image servers and large media files.

Better image error reporting
Image download failures now provide clearer error messages, including HTTP response details and more helpful explanations when an image source is blocked or inaccessible.

Listing Status & Draft Tracking

Draft listing creation logging
Added logging when a new listing is created as Draft, making it easier to identify which property status triggered it.

Status-change draft tracking
Improved visibility into listing status updates by logging before/after transitions whenever a status change moves a listing into Draft.

Safer post status handling
Invalid or unrecognised post statuses sent from FeedSync are now ignored and logged as warnings instead of being applied automatically, improving sync reliability and preventing unexpected listing behaviour.

1.0.17

1.0.17

• Feature: Monitor API enhancements for sync data.

1.0.16

• Fix: 200 success status for already deleted listing when received listing.deleted webhook request.

1.0.15

• Fix: Better listing finding based on Feedsync Unique ID and unique ID.

1.0.14

• Fix: Duplicate staff issue.
• Fix: Image download size check replaced wp_max_upload_size() (a browser-upload limit) with a generous 50 MB server-side cap, filterable via eplfs_max_image_download_size, preventing false “Image file is too large” rejections on default dev environments.
• Fix: Deleting a listing via webhook or admin now cancels any pending/in-progress queue items for that listing before the post is removed, preventing orphaned image jobs.
• Fix: EPL post types (property, rental, land, etc.) are now automatically enabled in EPL settings when an incoming listing uses a post type that was not yet activated.
• Enhancement: Listing post_author is now set to the primary agent’s WordPress user ID on create and update, keeping the WP author in sync with the assigned agent.
• Enhancement: Tools page — new “Author Mismatch” diagnostic tool with Dry Run and Fix modes to correct listings where post_author does not match the resolved property_agent user.
• Enhancement: Dashboard System Health widget now shows Max Upload Size (with php.ini hint), GD Library version, and Imagick availability/version.

1.0.13

• Duplicate images per listing fixes.

1.0.12

• Dashboard updates like filtering sorting queue items converting failed to pending.

1.0.11

• Initial pre launch version.