WP to XML

Tag: property feed

  • Case Study 13: Building and Maintaining Custom Real Estate XML Feeds for a Multi-Website Property Business

    Client Overview

    The client operates multiple real estate websites and needed custom XML feeds to distribute property listings to different property networks and platforms.

    The initial requirement was relatively simple: create an XML feed compatible with the Houzez WordPress real estate plugin.

    What started as a single-feed project developed into a long-term technical collaboration involving multiple websites, property-feed formats, custom filtering rules, additional XML fields, feed troubleshooting, and performance improvements as the number of listings grew.

    The project began in May 2023 and continued through subsequent feed development and maintenance requests.

    The Challenge

    The client needed to connect WordPress-based real estate websites with external property networks using specific XML formats.

    The main challenges included:

    • Generating XML feeds from WordPress real estate data
    • Working with the Houzez and RealHomes property systems
    • Mapping WordPress property fields to external XML structures
    • Supporting different property types and values
    • Creating feeds for multiple property portals
    • Filtering properties based on backend options
    • Excluding sold or unwanted properties
    • Supporting additional XML fields as requirements evolved
    • Correctly handling property prices
    • Including property images and videos
    • Supporting different feed URLs using the same underlying data
    • Troubleshooting XML parsing and accessibility issues
    • Scaling the feed as the number of properties increased

    The client also wanted the solution to be reusable across multiple websites rather than creating a completely different system for every website.

    Phase 1: Houzez XML Feed Development

    The relationship started when the client contacted me looking for an XML feed for the Houzez plugin.

    The first requirement was to develop a WordPress plugin capable of generating a Nestopa XML feed from the staging website.

    The client specifically asked whether the plugin could subsequently be used on multiple websites using Houzez.

    I confirmed that the plugin could be developed to work with the Houzez environment.

    The initial feed was developed and tested, including adjustments to property-type mapping.

    For example, the client changed property values such as:

    • Condo
    • House
    • Land
    • Office
    • Shop
    • Warehouse
    • Hotel
    • Building
    • Villa

    A custom mapping was then added so that the website’s Villa property type could be mapped to the required House value in the destination feed.

    This established the foundation for the later feed work.

    Phase 2: Multiple XML Feeds for HuaHinJapan.com

    After the first successful implementation, the client asked whether the same system could be adapted for HuaHinJapan.com.

    The project expanded to multiple property-network feeds.

    The feeds included:

    • Proppit
    • Nestopa
    • Listanza

    A separate URL was also created for the Proppit feed so the same feed could be accessed using another filename for a different integration requirement.

    The completed feed URLs included separate Proppit, Nestopa and Listanza endpoints.

    This demonstrated an important advantage of the approach: one WordPress property database could feed multiple external platforms through different XML formats and endpoints.

    Handling Feed Accessibility Problems

    The XML itself was functioning correctly, but the client’s technical team later reported that the Nestopa feed could not be accessed from their server because the feed appeared to be blocking bots.

    Rather than assuming the XML structure was incorrect, the issue was investigated separately as an accessibility/security problem.

    An alternative feed location was provided for testing, and the client was advised to check whether an anti-spam plugin was interfering with external access.

    This distinction between feed-generation problems and server-access problems was important when troubleshooting the integration.

    Phase 3: Filtering Property Listings

    The requirements became more sophisticated as the client’s property portfolio grew.

    For the Nestopa feed, the client requested that properties marked as Sold should be excluded.

    The feed was subsequently updated specifically for this requirement.

    Later, the client requested a Proppit feed for another website that would include properties only when a specific backend Proppit option was selected.

    A custom WordPress plugin was developed to apply that condition when generating the XML feed.

    This transformed the feed from a simple “export everything” system into a rules-based property syndication feed.

    Phase 4: Images, Prices and Property Metadata

    One of the recurring challenges with real estate XML feeds is ensuring that all important property information is transferred correctly.

    The client received feedback that some listings were being published without images because the XML did not contain the required pictures information.

    The feed was updated to include the required picture data.

    A specific property was also identified as missing the required price information, which was investigated and corrected.

    Later, a pricing issue occurred because the original rent-price field had been removed from the website.

    The feed was adapted to use the site’s “Sale or Rent Price (Only digits)” field instead, restoring the correct price information in the XML.

    Phase 5: Adding the “DeBoost” Logic

    The client later introduced a more advanced requirement for Proppit.

    They wanted properties to be promoted by default, while allowing administrators to disable promotion for individual listings.

    The requested XML behavior was:

    • Default property → <is_boosted>TRUE</is_boosted>
    • Property marked for removal/deboost → <is_boosted>FALSE</is_boosted>

    The feed was updated to derive the value from the website’s backend option.

    The implementation was based on the WordPress field:

    inspiry_remove_proppit_boost

    The client subsequently confirmed that the implementation was working correctly.

    This was an example of converting a WordPress backend workflow into XML business logic.

    Phase 6: Expanding the Feed With Additional Fields

    As the client’s XML requirements evolved, additional property information was added.

    One example was the Project Name field, which needed to appear in the Nestopa XML under the project tag.

    Another requirement was adding the property floor number.

    The client specified that the floor field should be optional and only appear when the value was available. The implementation connected the WordPress custom field inspiry_floor_level to the XML floor tag.

    The completed implementation was subsequently connected to both Proppit feed versions.

    Phase 7: Supporting Larger Property Inventories

    The number of properties eventually increased significantly.

    At one stage, the client requested a separate version of the Proppit feed containing approximately 550 properties, rather than applying the existing Proppit2 filtering rule.

    A second version of the feed was created:

    proppit_xml_feed_v2.xml

    This allowed the client to maintain different feed purposes without disrupting the original feed.

    As the property database continued to grow, pagination eventually became necessary.

    In August 2025, the client reported a critical issue with the HuaHinJapan Nestopa feed. The solution involved introducing pagination because the number of properties had increased.

    The proposed architecture was to combine the paginated results into a final static XML file periodically, allowing the receiving system to continue downloading a single feed.

    This provided a practical way to handle a growing property inventory while preserving the existing integration model.

    Phase 8: Video and Multimedia Support

    The project also evolved beyond basic property information.

    The client later requested support for YouTube videos in the Proppit XML.

    The feed was updated with a dedicated videos structure so that video URLs could be included separately from other virtual-tour information.

    The videos tag was subsequently added to both Proppit feed versions.

    This was particularly important for property syndication because multimedia information can be lost if it is not explicitly mapped into the destination XML format.

    Ongoing Troubleshooting and Maintenance

    The project continued to require occasional maintenance after the original development.

    Examples included:

    XML parsing issue

    In May 2024, the client’s development team reported an XML parser error indicating that the receiving system was not recognizing the beginning of the XML document.

    The feed was checked, and the existing Proppit feed was confirmed to be functioning from the website side.

    Feed availability issue

    In October 2024, the HuaHinJapan Nestopa feed generated an XML parsing error:

    xmlParseEntityRef: no name

    The client requested a correction, and the feed was subsequently restored so that it could be reprocessed by the receiving system.

    Property removal issue

    In January 2025, the client reported that a property whose Proppit option had been removed was still appearing in the XML feed.

    The feed was investigated and subsequently updated.

    These requests demonstrate that XML feed development is not always a one-time task. Changes to WordPress fields, property workflows, external requirements and third-party importers can require ongoing feed maintenance.

    The Technical Approach

    The overall solution evolved around several core principles:

    WordPress Property Data → Custom Mapping Logic → XML Generation → Dedicated Feed URL → External Property Platform

    The implementation included:

    • Custom WordPress plugins
    • Property-field mapping
    • Conditional property filtering
    • Property-status filtering
    • Custom XML tags
    • Image mapping
    • Price mapping
    • Video mapping
    • Backend checkbox integration
    • Multiple feed endpoints
    • Separate feed versions
    • XML troubleshooting
    • Pagination for larger inventories
    • Static feed generation for external consumption

    Rather than forcing every external platform to consume the same generic feed, individual XML structures could be adapted to the requirements of the receiving platform.

    Results

    The project grew from a single XML feed requirement into a long-running feed-development relationship covering multiple websites and property networks.

    Key outcomes documented in the project include:

    • Custom XML feed developed for a Houzez-based website
    • Reusable approach for multiple WordPress property websites
    • Proppit XML feeds
    • Nestopa XML feeds
    • Listanza XML feed
    • Multiple feed URLs for different integration requirements
    • Property-type mapping
    • Sold-property filtering
    • Proppit checkbox filtering
    • Approximately 550-property feed version
    • Image support
    • Price corrections
    • Project-name mapping
    • Floor-number mapping
    • is_boosted / DeBoost logic
    • YouTube video support
    • XML troubleshooting and maintenance
    • Pagination strategy for increasing property inventories

    Most importantly, the client repeatedly returned with new websites and new feed requirements. The conversation records show requests in 2023, 2024 and 2025, including a new Nestopa feed for Star Property and later work on the growing HuaHinJapan feed.

    Client Feedback

    The client repeatedly expressed satisfaction with the work.

    Examples include:

    “You are the best!”

    and later:

    “Ranjit, excellent work! Very happy again.”

    The client also described the XML work as “amazing” when referring to the Proppit implementation.
    These comments are particularly meaningful because they came after the initial project had evolved into ongoing technical support and increasingly complex feed requirements.

    Key Takeaways

    This project demonstrates that a real estate XML feed is more than simply converting WordPress posts into XML.

    A production property feed may need to handle:

    Data Mapping
    Different property platforms require different field names, structures and accepted values.

    Business Rules
    Only selected properties may need to be exported, while sold or deboosted properties may need different treatment.

    Multimedia
    Images, floor plans, virtual tours and YouTube videos may require dedicated XML structures.

    Data Accuracy
    Property prices and custom fields must remain synchronized with the WordPress backend.

    Scalability
    A feed that works with a small number of properties may require pagination or other optimization as the inventory grows.

    Third-Party Compatibility
    External platforms may introduce parser, accessibility or validation requirements that need investigation separately from the WordPress implementation.

    Conclusion

    What began as a small XML-feed project became a long-term technical collaboration involving multiple real estate websites, multiple property portals and numerous custom feed requirements.

    The project is a good example of how a well-designed WordPress XML feed can evolve alongside a real estate business—from a basic property export to a flexible syndication system capable of handling filtering, custom fields, multimedia, business rules and larger property inventories.

    Need a custom XML feed for your WordPress real estate website?

    I can develop custom XML, RSS or JSON feeds based on your WordPress fields, real estate plugin, API documentation and destination portal requirements.

  • Case Study 12: Building a Zillow New Construction XML Feed from WordPress

    Project Overview

    A custom home builder approached us to develop a Zillow New Construction XML feed directly from their WordPress website.

    The website was built with WordPress and the Avada theme, while the core real estate data was managed through WP Toolset custom post types, custom fields, and taxonomies.

    The primary objective was to create a structured XML feed containing communities, floor plans, and available properties, while matching as many of Zillow’s required parameters as possible.

    Client: J Thomas Homes
    Website: jthomashomes.com
    Feed Type: Zillow New Construction XML Feed
    Platform: WordPress
    Data Management: WP Toolset
    Theme: Avada
    Builder ID: 7681

    The Challenge

    The project presented several data-mapping challenges because the information required for the Zillow feed was stored across different parts of the WordPress website.

    Most of the property information was stored using WP Toolset custom fields and taxonomies, including the structured information required for communities, floor plans, and properties.

    However, the property’s photo galleries were managed separately through the Avada theme’s gallery functionality.

    This meant that a successful solution needed to combine information from multiple WordPress data sources into a single Zillow-compatible XML structure.

    The client specifically highlighted that the photo galleries were essential because the images also needed to be submitted to Zillow.

    The existing website also had WP All Export Pro installed and being used for another business. An existing implementation had successfully handled the integration of photo galleries, providing a useful reference for the required approach.

    Project Requirements

    The client requested a feed capable of representing:

    • New construction communities
    • Single-family floor plans
    • Townhome floor plans
    • Available properties
    • Property and floor-plan information
    • Images from Avada photo galleries
    • Data stored in WP Toolset custom fields
    • Data stored in WP Toolset taxonomies
    • Zillow-specific parameters and identifiers
    • Lead-routing information

    The goal was to match as many of Zillow’s available parameters as possible while maintaining the existing WordPress setup.

    Community Selection

    During development, the client specified that only five communities should initially be included in the XML feed:

    1. Ogden Towns
    2. Nibley Meadows
    3. Presidents Park
    4. Springville Towns
    5. West Fields

    This allowed the feed to be focused on the specific communities required for the initial Zillow submission.

    Zillow Builder Identification

    Another important requirement was obtaining the correct Zillow identifier.

    The client initially indicated that they were waiting for the account information from Zillow. Zillow subsequently provided the unique Builder ID 7681, which was then used for the feed configuration.

    Using the correct builder identifier is important when submitting a builder’s inventory to a third-party real estate portal because it connects the feed data with the appropriate builder account.

    Data Integration Approach

    The key technical challenge was bringing together data stored through different WordPress systems.

    The implementation needed to work with:

    WP Toolset

    • Custom post types
    • Custom fields
    • Taxonomies
    • Community information
    • Floor-plan information
    • Property information

    Avada

    • Photo galleries
    • Property images

    The resulting feed needed to transform this WordPress data into the XML structure expected by Zillow.

    Rather than requiring the client to restructure their existing website, the feed was designed around the data already maintained within WordPress.

    This approach reduced the need for duplicate data entry and allowed the website to remain the primary source of property information.

    Photo Gallery Integration

    One of the more complex parts of the project was handling images.

    The majority of the XML information could be obtained from WP Toolset, but the images were maintained through Avada’s photo gallery system.

    Therefore, the feed generation process needed to retrieve the appropriate gallery images and associate them with the corresponding communities, floor plans, or properties.

    The existing WP All Export Pro implementation on the website demonstrated that the gallery data could be integrated successfully, which provided a useful reference when developing the new feed.

    Lead Routing

    The Zillow feed also required lead-routing information.

    The client was asked to provide an email address where Zillow leads should be delivered. They indicated that if only one email address was supported, leads should be routed to their primary email, while if two addresses were supported, a second address could also be included.

    This ensured that the feed was not limited to property data alone but also incorporated the contact information required for lead handling.

    Result

    After the feed was prepared, the client submitted the XML to Zillow for review.

    On June 3, 2025, the client confirmed that the feed had been submitted to Zillow and that Zillow’s support team was reviewing it to ensure everything was correct.

    The project demonstrated how a WordPress-based real estate website can be connected to a major property portal even when the required information is distributed across:

    • Custom post types
    • Custom fields
    • Taxonomies
    • Theme-managed galleries
    • Existing WordPress export configurations

    Key Takeaways

    1. WordPress can serve as the central data source

    A real estate website does not necessarily need a separate database or property management platform to generate a portal feed. Structured WordPress data can be transformed into a portal-specific XML format.

    2. Custom fields require careful mapping

    Real estate websites frequently store information in custom fields and taxonomies. Each field must be mapped appropriately to the destination portal’s XML requirements.

    3. Images can add another layer of complexity

    When images are managed separately from the primary property data, the feed-generation process needs to combine both sources correctly.

    4. Existing integrations can provide valuable references

    The existing WP All Export Pro configuration provided useful insight into how the website’s Avada galleries were being handled, helping inform the new feed implementation.

    5. Portal-specific requirements matter

    A successful XML feed is not simply an export of WordPress content. It needs to follow the destination portal’s expected structure, identifiers, fields, and submission requirements.

    Conclusion

    This project involved developing a Zillow New Construction XML feed for a WordPress-based home builder website, combining structured WP Toolset data with Avada-managed photo galleries.

    The final solution was prepared around the client’s existing WordPress architecture and included the required communities, builder identification, property information, images, and lead-routing details.

    The completed XML was then submitted to Zillow for review, providing the client with a portal-ready feed for their new construction inventory.

    Need a custom XML feed for Zillow, Realtor portals, real estate marketplaces, or another property platform?

    We can develop custom WordPress XML/RSS feeds that map your existing custom fields, taxonomies, property data, and images into the format required by your target portal.

  • Case Study 10: Building and Maintaining a Multi-Portal Real Estate Feed System for WordPress

    From One Custom XML Feed to a Multi-Portal Property Distribution System

    Real estate websites often need to distribute property listings to multiple portals, marketplaces, advertising platforms, and property aggregators. The challenge is that each platform can require a completely different XML, JSON, or CSV structure, while the source website may use a WordPress theme such as Houzez with custom fields, taxonomies, multilingual data, and different measurement formats.

    This case study describes a long-term project for a real estate website using WordPress, Houzez, WP All Import, and WP All Export.

    The project began with a relatively small requirement: fixing several fields in an existing WP All Export template for a property portal. Over time, the requirement expanded into a collection of custom feeds and ongoing feed maintenance.

    The initial client requirement included generating property feeds for external portals while continuing to use the existing WP All Export setup where possible. The client specifically needed help with image URLs, furniture/status values, and conversion of Thai land measurements such as square wah and rai into square metres.

    The Initial Challenge

    The client’s WordPress website contained property data in different formats.

    Some of the major challenges included:

    • Multiple property images needed to be output as individual URL elements.
    • Values such as “Furnished” needed to be cleaned before being sent to the destination portal.
    • Status values required transformation.
    • Land measurements could be stored as square wah, rai, or combined formats such as Rai-Ngan-Wah.
    • Property types needed to be mapped from WordPress parent/child categories into the destination portal’s terminology.
    • Virtual-tour information needed to be converted into the format required by the portal.
    • Different portals required different XML structures.

    The first approach was to see whether the existing WP All Export template could be modified rather than immediately replacing it with a custom plugin. A custom plugin was kept as the fallback option if the existing export system could not handle the requirements.

    This approach helped avoid unnecessary redevelopment and allowed the existing WordPress workflow to remain part of the solution.

    Phase 1: Proppit XML Feed

    The first major deliverable was a custom XML feed for Proppit.

    The feed was initially developed around the client’s existing property data and then refined based on real output and feedback.

    One important requirement was converting land measurements and removing decimal values from both land area and floor area. The feed was subsequently updated to round floorArea and plotArea.

    Complex Property Data Mapping

    The project involved more than simply copying WordPress fields into XML tags.

    For example, property types had to be interpreted according to the destination portal’s requirements. Later revisions included distinguishing between residential and commercial property types and mapping categories such as:

    • House
    • Condo
    • Townhouse
    • Shophouse
    • Office
    • Hotel
    • Factory
    • Retail space

    The client provided examples where a property could have multiple WordPress categories, requiring custom logic to determine which category should become the primary destination value.

    This illustrates an important aspect of custom feed development: source taxonomy and destination taxonomy rarely match one-to-one.

    Diagnosing WP All Export

    An interesting technical problem appeared when the WP All Export template worked in Preview mode but failed during the actual export.

    Testing showed that individual properties could be exported successfully and that reducing the number of XML tags allowed all 88 properties to process. The investigation indicated that the problem was likely related to the number of database queries and server resource limitations during the larger export.

    The recommendation was to investigate hosting limits such as maximum execution time and memory rather than incorrectly blaming the property data or custom functions.

    Meanwhile, the custom feed continued to provide a working alternative.

    This was an important distinction:

    A feed can be logically correct while the export mechanism used to generate it is still limited by server resources.

    Virtual Tour and Feed Formatting Fixes

    The Proppit feed later required the virtual-tour field to contain a direct link rather than embed code.

    The feed was updated accordingly.

    A further issue appeared where one property was receiving an incorrect virtual-tour base URL because different properties could use different virtual-tour providers.

    The feed logic was adjusted so that the property-specific virtual-tour URL could be handled correctly rather than applying one universal URL to every listing. The client confirmed that the corrected virtual-tour link was displaying properly.

    Expanding Into Multiple Feeds

    After the initial Proppit implementation, the project expanded significantly.

    The client requested additional feeds for other real estate platforms and advertising systems, including:

    • Thailand Housing Market
    • Baan Finder
    • Living Insider
    • Facebook Commerce Manager
    • Google-related feeds
    • Google Ads real estate CSV
    • Green-Acres
    • Nestopa
    • Propertyhub JSON
    • XML2U / Properstar-related distribution

    The client also maintained a Google Sheet to track the different feeds and requirements.

    This changed the nature of the work from a one-off XML customization into an ongoing multi-feed property distribution system.

    Google Feed and Local Inventory

    The Google feed required additional destination-specific fields and formatting.

    Updates included:

    • Resolving line-break formatting.
    • Removing an unwanted price prefix.
    • Adding store_code.
    • Adding quantity.
    • Creating a separate feed for local inventory because the destination required a different filename.

    The primary Google feed and Proppit feed were updated accordingly.

    A separate local inventory feed was subsequently created:

    google_local_inventory_xml_feed.xml

    The feed was also repaired after a PHP version change caused the XML feeds to stop working. The client had moved the hosting environment to PHP 8.2.4, and the feed plugins were upgraded to work with the newer environment.

    This demonstrated another recurring challenge with WordPress feed systems: hosting and PHP environment changes can affect custom feed code even when the property data itself has not changed.

    Facebook Commerce Manager Feed

    The project also expanded into a Facebook Commerce Manager XML feed.

    The feed required destination-specific handling for fields such as:

    • Property type
    • Pet policy
    • Area size
    • Neighborhood
    • Address information
    • Page ID
    • Security deposit
    • Utilities
    • Video

    The feed was revised several times based on Facebook’s validation feedback. Eventually, the video field was removed because the destination required a direct downloadable video URL rather than a normal video-hosting page URL.

    This is another example of why feed development is not simply an XML-generation exercise. The destination platform’s validation rules must be incorporated into the transformation logic.

    Baan Finder and Living Insider

    The next stage involved creating feeds for Baan Finder and Living Insider.

    Baan Finder required more complex property-type mapping.

    For example, a property categorized as commercial on the WordPress website could still need to be mapped to SHOPHOUSE, HOTEL, FACTORY, OFFICE, or another destination-specific type depending on information contained in the title or description.

    Living Insider introduced another layer of complexity around land measurements.

    Different fields were required depending on property type, including:

    • Square metres
    • Square wah
    • Rai
    • Ngan
    • Wah
    • Separate land-area components
    • Thai and English titles/descriptions
    • Condo-specific values
    • Multiple image URLs

    The client specifically identified cases where a value such as 174 square wah needed to be separated into the appropriate Rai/Ngan/Wah fields rather than simply placing the entire number into one field.

    Green-Acres Integration

    In 2025, another feed was added for Green-Acres.

    The feed was developed as a dedicated XML integration and subsequently updated with destination-specific fields including:

    • English title
    • Province
    • Sub-district/district
    • Property ID
    • Favorite status
    • Included fees
    • Agency rate type

    After submission, the destination platform reported a video URL problem. The video URL issue was diagnosed and corrected, after which the feed was reported as working.

    Long-Term Feed Maintenance

    One of the most interesting aspects of this project is that the work did not end after the initial feed development.

    As the website, destination platforms, hosting environment, and property data changed, new requirements continued to appear.

    Examples included:

    • New destination validation rules.
    • Changes to property classifications.
    • New PHP versions.
    • Different language requirements.
    • Changes to virtual-tour providers.
    • New property filtering requirements.
    • Feed performance concerns.
    • Listing limits imposed by external platforms.
    • Changes in external APIs.
    • New image-handling requirements.

    For example, in 2025 the client became concerned about the number of listings being refreshed on Properstar. A strategy was discussed to change only a limited number of property IDs per day instead of changing all IDs simultaneously. The proposed approach was approximately 15 listings per day for a 500-listing cycle.

    Later, Nestopa introduced a limit on the number of listings displayed under its free plan, leading to another requirement to prioritize particular property listings and control how frequently listing IDs changed.

    This shows how a feed system can evolve into a business-rule engine, rather than remaining a static XML generator.

    Feed Filtering and Automation

    As the number of feeds increased, the client wanted greater control over which properties were included.

    The proposed feed-management logic included filtering by:

    1. Property ID prefixes.
    2. Minimum sale price.
    3. Minimum rental price.
    4. Custom fields.
    5. Specific properties to include.
    6. Specific properties to exclude.
    7. Property status.
    8. Other feed-specific conditions.

    For example, a custom field such as fave_luxury = Yes could be used to select properties for a particular luxury-property feed.

    This approach provided much greater flexibility than hard-coding a completely different selection rule into every feed.

    Performance Became a Separate Challenge

    As the number of properties and feeds increased, feed-generation performance became an important concern.

    The client reported that some XML URLs could take several seconds to load and, in some cases, make the browser appear unresponsive.

    The website developer subsequently implemented Redis caching for the feed outputs. According to the project discussion, the site was generating approximately 15 XML/JSON feed outputs from more than 800 properties and many custom fields. The caching layer was intended to make repeated feed requests significantly faster and automatically refresh the cache after imports.

    The project therefore evolved beyond field mapping into considerations involving:

    • Database queries
    • Feed generation performance
    • Caching
    • Import/export workflows
    • Background processing
    • Feed refresh cycles

    Handling Large Feeds

    Another scalability issue emerged when Living Insider imposed a limit of 1,000 records per XML or CSV file.

    Instead of allowing the feed to grow indefinitely, the proposed solution was to introduce pagination so the listings could be divided into multiple parts.

    This is a useful example of designing around an external platform’s technical limitations rather than trying to force the destination to accept an oversized feed.

    Land Measurement Standardization

    The project eventually exposed a larger architectural issue: property data from different agencies did not use a consistent land-measurement format.

    Some providers supplied:

    • Square wah
    • Square metres
    • Rai
    • Rai + square wah
    • Rai + Ngan + square wah

    The client wanted to establish a consistent base measurement that could then be converted into other units.

    The requirement included creating import-side PHP logic so that incoming data could be normalized before it was used by the different feeds. The client specifically identified mixed-data providers such as Perfect Homes and Isara Real Estate as requiring special handling.

    This was an important shift from feed-level conversion to data normalization at the source/import level.

    Once data is normalized properly, multiple feeds can use the same underlying property values instead of implementing independent conversion logic repeatedly.

    Extending the System Beyond XML

    The project also expanded beyond traditional XML feeds.

    The client wanted to generate CSV data for a video-generation platform called CreateOMate, with the eventual goal of connecting the data to automation tools for social media publishing.

    The CSV needed to contain:

    • Individual photo URLs in separate columns.
    • A specific location structure.
    • Child property categories rather than parent/child category strings.
    • Conditional price formatting.
    • Potential HTML cleanup.

    The existing WP All Export template was modified using PHP functions to support these requirements.

    This demonstrated that the same WordPress property database could serve many different downstream purposes:

    Website → XML feeds → JSON feeds → CSV exports → advertising → social-media content

    What Made This Project Challenging?

    The biggest challenge was not creating XML syntax.

    The real difficulty was translating one complex real estate database into multiple destination-specific data models.

    The same property could require different:

    • Property types
    • Measurement units
    • Language values
    • Address structures
    • Image formats
    • Video formats
    • Status values
    • Price formats
    • Filtering rules
    • Required fields
    • Optional fields

    A field that worked correctly for one destination could be wrong for another.

    For example, HTML formatting could be useful in one feed but unacceptable in another. Similarly, a universal property-type rule could create incorrect classifications when a property had multiple categories.

    The project therefore required continuous validation against the actual destination requirements.

    Results

    The project evolved from a single custom XML-feed requirement into a long-term feed-development and maintenance relationship.

    The conversation records show work involving multiple destination feeds and formats, including Proppit, Google, Facebook, Thailand Housing Market, Baan Finder, Living Insider, Green-Acres, Nestopa, Propertyhub, and XML2U/Properstar-related integrations.

    The client repeatedly returned with additional feed requirements and described the collaboration positively. At one point, after multiple feed updates, the client stated that it was “great to have been able to make this contact” and asked to continue with additional feeds.

    The relationship subsequently continued into later years with additional feed modifications, filtering, performance, listing-refresh, and data-normalization requirements.

    Key Lessons From the Project

    1. Start With the Existing System

    The initial goal was not to replace WP All Export unnecessarily. The existing workflow was investigated first.

    This can reduce development time and preserve the client’s familiar workflow.

    2. Normalize Data Where Possible

    Repeated conversion logic across individual feeds can become difficult to maintain.

    Standardizing data during import can make downstream feeds significantly easier to manage.

    3. Every Portal Has Different Rules

    There is no universal “real estate XML feed.”

    Each destination may have different requirements for:

    • Categories
    • Measurements
    • Images
    • Descriptions
    • Languages
    • Videos
    • Pricing
    • IDs
    • Filtering

    4. Feed Development Requires Real-World Testing

    A feed can be valid XML and still be rejected by the destination.

    The project repeatedly required testing against actual portal feedback and adjusting the mapping accordingly.

    5. Scaling Changes the Architecture

    As the number of properties and feeds grows, performance becomes important.

    Caching, filtering, pagination, and controlled refresh cycles may become just as important as the XML mapping itself.

    6. Feed Maintenance Is Often More Valuable Than One-Time Development

    External platforms change their requirements.

    Websites change their data structure.

    Hosting environments change.

    New property sources are added.

    New portals are introduced.

    A feed that worked perfectly when created may require maintenance months or years later.

    Conclusion

    This project is a good example of how a seemingly small WordPress XML-feed request can evolve into a much broader data-integration system.

    What started as a request to fix several fields in a WP All Export template eventually involved custom XML, JSON, and CSV feeds; complex property-type mapping; Thai land-measurement conversion; multilingual data; virtual tours; image handling; filtering; pagination; caching; PHP compatibility; external-platform validation; and long-term maintenance.

    The central lesson is simple:

    A successful real estate feed is not just an XML document. It is a data-transformation layer between the property’s source database and the unique requirements of every destination platform.

    When that transformation layer is designed carefully, the same WordPress property database can support many different portals and marketing channels without requiring the property data to be manually recreated for every platform.

  • Case Study 3: Real Estate Feed Development

    WordPress Custom Fields → XML/JSON Mapping → Portal-Ready Property Feeds

    The Challenge

    A real estate business operating in Thailand needed to distribute property listings from its WordPress website to multiple property portals.

    The website contained a large and continually changing inventory of properties for sale and rent. The challenge was not simply to generate an XML file. Each destination portal had its own feed structure, required fields, validation rules, filters, and data expectations.

    The project initially involved creating a feed for Nestopa, followed by additional feeds for Proppit and PropertyHub.

    The requirements evolved as the portal integrations were tested in real-world conditions, making reliable field mapping and data handling particularly important.

    The Starting Point

    The first requirement was relatively straightforward: generate a Nestopa XML feed from the property’s WordPress website.

    A custom WordPress plugin was developed to transform property data into the XML structure required by the portal.

    The initial implementation was delivered as a dedicated feed plugin, with the source code included and the feed made available through a public XML endpoint.

    The project then expanded.

    The client required another feed for Proppit, initially restricted to sale properties, with additional contact fields including:

    • Phone
    • WhatsApp
    • LINE
    • Facebook

    The Proppit feed was generated directly from the WordPress property data and made available through a public XML endpoint.

    From Simple XML Generation to Data Transformation

    As more portals were introduced, it became clear that each integration needed its own mapping logic.

    The WordPress website contained the source property information, while the portals expected their own specific structures.

    The basic architecture therefore became:

    WordPress property data

    ↓

    Custom field extraction

    ↓

    Data filtering and transformation

    ↓

    Portal-specific field mapping

    ↓

    XML/JSON generation

    ↓

    Portal validation and import

    This approach allowed the same WordPress property database to support multiple destinations without requiring the website’s core property structure to be redesigned for every portal.

    Handling Property Filters

    One important requirement was controlling exactly which properties should appear in a feed.

    For example, the Proppit feed needed to distinguish between properties for sale and properties for rent.

    At one stage, the client had approximately:

    • 620 properties for sale
    • 115 properties for rent

    The requirement was to include the sale properties while excluding rentals from that particular feed. The feed was checked against the website’s property counts to confirm that the expected listings were being exported.

    Later, the requirements became more sophisticated.

    The client requested a feed containing both sale and rental properties, with rental properties filtered according to a minimum value of 25,000 THB.

    A separate requirement also specified that, when the website contained more than 1,000 properties, the feed should continuously select the 1,000 newest properties rather than attempting to export the entire database.

    This illustrates an important part of real estate feed development:

    A portal feed is not necessarily a copy of the website. It is a controlled data export based on the destination’s business rules.

    Mapping WordPress Data to Portal Fields

    Real estate websites often store information in custom fields rather than standard WordPress post fields.

    The feed therefore needed to identify the appropriate property fields and transform them into the format expected by each portal.

    The work included mapping information such as:

    • Property reference
    • Property type
    • Sale/rental status
    • Price
    • Property details
    • Land size
    • Contact information
    • Project information
    • Project ID
    • Images
    • Other portal-specific attributes

    This field-by-field mapping is where much of the practical complexity of a real estate feed lies.

    A feed can be technically valid XML or JSON and still be rejected by a portal if a value does not conform to the portal’s expected format.

    Solving Portal-Specific Validation Errors

    The Proppit integration demonstrated this clearly.

    After the feed was delivered, the portal reported an error involving an Amenity value that did not match its required format. The feed was rechecked and updated, and a cache-busting query parameter was used when necessary so that the latest feed version could be retrieved instead of an older cached response.

    This type of troubleshooting is an important part of production feed development.

    The process was not simply:

    Generate XML → Done

    Instead, it became:

    Generate → Validate → Submit → Review portal errors → Correct mapping → Re-test → Confirm

    PropertyHub: A More Complex Integration

    The PropertyHub integration introduced a substantially different requirement.

    The portal supplied a JSON feed schema and documentation, along with a spreadsheet containing project information.

    The feed needed to provide project information in addition to the normal property data.

    The challenge was that projects were not properties.

    The client’s WordPress website already contained a property management workflow, while the PropertyHub integration required project names and project IDs to be associated with properties for export.

    This created a data-mapping problem between:

    Property → Project Name → Project ID → PropertyHub Feed

    Building Project Mapping

    The project list was provided separately from the property data.

    The solution was to map the project information so that the feed could retrieve the appropriate project name and corresponding project ID when generating the PropertyHub JSON feed.

    The client eventually configured project information in the backend as a selectable value associated with properties.

    The feed could then use that information when constructing the outgoing PropertyHub data.

    The requirement was particularly important because PropertyHub expected both the project name and numerical project ID, while Proppit did not require the same project information.

    This meant the same WordPress property data had to support two different portal requirements without unnecessarily exposing project information elsewhere on the website.

    Avoiding Changes to the Front-End Property Structure

    One of the lessons from this stage was that supporting an external portal should not accidentally alter how the website works for visitors.

    An initial project-list mapping approach caused project records to appear in an inappropriate location on the website. The client reported that thousands of project records had appeared and had to be removed.

    The requirement was clarified:

    Projects were reference data for the feed and backend workflow, not additional front-end property listings.

    The project mapping was subsequently handled in a way that allowed the property information and project information to remain separate while still providing the required values to the outgoing feed.

    This became an important architectural consideration:

    External feed requirements should be integrated into WordPress without disrupting the site’s existing content model or front-end experience.

    Handling Project Names and IDs

    Another challenge was that some project names already contained numbers.

    For example, a project might contain a number as part of its actual name, while PropertyHub required a separate numerical project ID.

    This created ambiguity when attempting to derive the ID from the project-name field.

    The project therefore required a consistent naming and parsing strategy.

    The client and developer tested different formats and discussed using a delimiter such as:

    Project Name – 9999

    rather than:

    Project Name 9999

    The final approach focused on making the feed parser resilient to spaces and formatting variations rather than requiring a large manual change to the website’s existing data.

    This is a good example of why real estate integrations often require more than straightforward XML templating.

    Debugging Data That Looks Correct

    One of the most challenging stages occurred after the PropertyHub feed was technically working.

    Some properties containing project names and IDs were successfully accepted, while others were not.

    The client provided examples where the backend data appeared correct, but the corresponding information was not being accepted by the portal.

    At one point, only 1,064 properties had been delivered successfully, despite substantially more properties being available.

    The investigation therefore moved beyond XML/JSON syntax.

    The feed itself could be valid while individual property records still contained values that the destination system could not process.

    The debugging process involved examining:

    • Project names
    • Project IDs
    • Missing IDs
    • Formatting
    • Spaces
    • Line breaks
    • Hidden characters
    • Property-level data
    • Portal validation results

    This distinction is critical when developing automated feeds:

    Feed validity and data validity are two different things.

    Working With Portal Validation Reports

    The PropertyHub integration included validation reports supplied by the portal.

    These reports made it possible to identify which property records were failing and investigate the underlying values.

    For example, one reported issue involved properties whose project name existed but whose project ID was missing.

    The solution was to ensure that the required project ID information was available in the property’s backend data before it was exported.

    This created a repeatable troubleshooting cycle:

    1. Generate the feed.
    2. Submit it to the portal.
    3. Review rejected records.
    4. Identify the problematic WordPress data.
    5. Improve the mapping or parsing logic.
    6. Correct source data where necessary.
    7. Generate the feed again.
    8. Re-submit and verify.

    Keeping Multiple Portals in Sync

    The project eventually involved several different destination formats:

    Nestopa

    A custom XML structure for the portal’s property requirements.

    Proppit

    A separate XML structure with contact information and property filtering.

    PropertyHub

    A JSON-based feed requiring project names and project IDs.

    Each destination had different rules.

    The WordPress website remained the central source of property information, while the feed layer transformed that information for each portal.

    This provided a much more scalable model than manually preparing separate property files for every destination.

    Ongoing Maintenance

    The project also demonstrated that feed development does not necessarily end when the first feed is generated.

    The client later requested relatively small operational changes, such as changing the contact email address used in the Proppit feed.

    Other requests involved:

    • Changing domains
    • Creating feeds for new domains using the same property data
    • Adjusting sale/rental filters
    • Updating contact information
    • Investigating missing properties
    • Fixing portal validation errors
    • Updating project mappings
    • Rechecking feed output after website changes

    For example, when the property website moved to a new domain while using the same underlying property inventory, the feed needed to be adapted to the new domain rather than treated as an entirely unrelated property database.

    The Result

    The project evolved from a basic WordPress XML feed into a multi-portal property data integration system.

    The final workflow allowed the real estate website to act as the central source while generating portal-specific output according to each destination’s requirements.

    Key capabilities included:

    • WordPress property data extraction
    • Custom field mapping
    • XML feed generation
    • JSON feed generation
    • Sale/rental filtering
    • Minimum-price filtering
    • Latest-property selection
    • Contact-field mapping
    • Project-name mapping
    • Project-ID mapping
    • Portal-specific formatting
    • Validation-error troubleshooting
    • Property-level data debugging
    • Domain/feed updates
    • Ongoing feed maintenance

    Key Takeaway

    Real estate feed development is more than generating an XML or JSON document.

    The real challenge is creating a reliable bridge between a WordPress property database and the specific data model expected by each external portal.

    In this project, the feed layer had to deal with changing requirements, multiple destinations, custom fields, project relationships, filtering rules, validation errors, and inconsistent source data.

    The result was a practical, portal-ready integration that could transform the website’s property information into the formats required by different property platforms.

    WordPress remains the source of truth.
    The feed handles the transformation.
    Each portal receives the structure and data it expects.

    That is the core principle behind a reliable custom real estate feed.

Powered by