WP to XML

Tag: WordPress XML 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 11: Google Shopping XML Feed for WordPress Custom Fields: Whitewater Tours Case Study

    Project Overview

    A client from Whitewater Tours needed a Google Shopping XML product feed for approximately 50 products on their WordPress website.

    The website used custom WordPress fields to store product information, and the client wanted that information converted into an XML feed that could be used with Google.

    The project was a good example of how a custom XML feed can be built around an existing WordPress data structure rather than requiring the client to manually maintain a separate product feed.

    Project Requirements

    The main requirements were:

    • Create a Google Shopping XML product feed.
    • Generate the feed from WordPress custom fields.
    • Support approximately 50 products.
    • Make the feed accessible through a dedicated XML URL.
    • Ensure newly added products could automatically appear in the feed.
    • Provide a solution suitable for submission to Google Merchant Center.

    The initial project budget was $50, with a three-day delivery requirement.

    Understanding the Client’s WordPress Structure

    The client explained that the products were already managed through WordPress and that the required information was stored in custom fields.

    Instead of creating a completely separate product database, the approach was to work with the existing WordPress content and transform the available product information into the required XML feed structure.

    This is an important consideration when developing feeds for WordPress websites.

    A feed should ideally work with the website’s existing data rather than forcing the site owner to maintain product information in multiple places.

    Creating the Custom XML Feed

    A custom WordPress XML feed solution was developed specifically for the website.

    The feed was designed to collect the relevant product information from WordPress and make it available through an XML endpoint.

    The resulting feed was intended to provide a direct URL that could be supplied to Google Merchant Center.

    The client also asked whether the feed would automatically include a new product when it was added to the website.

    The answer was yes.

    This meant the client would not need to manually recreate the XML feed every time a new product was published.

    WordPress Plugin Installation

    Because the website was running as a WordPress multisite, the plugin installation required some additional coordination.

    Initially, the required permissions were not available for installing the plugin directly.

    The client therefore uploaded the provided plugin package, after which the feed could be tested and refined.

    This is a common practical issue when working on client websites: the technical implementation may be straightforward, but access permissions and hosting configuration can affect the development workflow.

    Testing and Refinement

    The plugin was not considered finished immediately after installation.

    The client asked whether the work was complete once the plugin had been uploaded.

    The response was that the feed still needed to be checked and refined before being considered final.

    The goal was to make sure that the generated XML could be used as the feed source and that the client could subsequently submit the feed URL to Google Merchant Center.

    The client also confirmed that they would test the implementation and report any issues.

    Automatic Product Updates

    One of the useful features of the implementation was that the XML feed was connected to the site’s WordPress product data.

    The client specifically asked:

    If a new product is added, will it auto go to the XML feed?

    The answer was yes.

    This makes a custom feed considerably more useful for an active website because the feed can continue to reflect the site’s product catalog without requiring the site owner to manually edit an XML file every time a product is added.

    Expanding Beyond Google Shopping

    After the initial XML feed work, the client asked about another Google integration: Google Things to Do.

    This introduced a different type of feed requirement involving event and activity information.

    The discussion moved toward JSON feeds and customized data for individual events.

    The client was informed that the data structure on the website would need to be customized for each event and that the work could be started with a single event to verify the output before expanding the implementation.

    This demonstrated another advantage of working with custom feed development: once the underlying WordPress data and feed requirements are understood, similar structured-data integrations can be evaluated and developed around the same website.

    A Later Check: Feed Endpoint No Longer Available

    More than a year after the original implementation, the old Google feed URL was checked again:

    whitewatertours.com/google.xml

    The endpoint is currently returning a Page Not Found response.

    This does not necessarily mean that the original feed implementation failed. Websites are frequently redesigned, plugins are removed, URLs are changed, or WordPress configurations are modified over time.

    Because the current endpoint is no longer available, the next step is to determine whether the client still requires the Google Shopping feed and, if so, what has changed on the website since the original implementation.

    A follow-up was therefore sent to the client offering to investigate the issue and restore the feed if it is still required.

    Key Takeaways

    This project highlights several important considerations when creating custom XML feeds for WordPress websites.

    1. Work With Existing WordPress Data

    Using the website’s existing custom fields can eliminate unnecessary duplication and allow the feed to stay connected to the site’s product information.

    2. Automate Feed Updates

    Automatically generating the XML output means that new products can be incorporated into the feed without manually editing an XML file.

    3. Consider WordPress Multisite During Development

    Multisite installations can introduce additional permission and plugin-installation considerations that should be accounted for before development begins.

    4. Test Before Submitting the Feed

    A feed should be checked and refined before its URL is submitted to Google Merchant Center.

    5. Feed Maintenance Matters

    Even a working feed can become unavailable later because of website changes, plugin removal, URL changes, migrations, or other configuration changes.

    For this reason, an XML feed should be treated as part of the website’s ongoing technical infrastructure rather than a completely one-time task.

    Conclusion

    The Whitewater Tours project started with a straightforward requirement: convert approximately 50 WordPress products stored using custom fields into a Google Shopping XML feed.

    A custom WordPress feed solution was developed, installed on the client’s multisite environment, and prepared for testing and use with Google Merchant Center.

    The project also opened the door to discussing additional structured-data integrations such as Google Things to Do.

    The later discovery that the original /google.xml endpoint is no longer available also illustrates an important aspect of feed development: ongoing website changes can affect previously working integrations.

    For businesses relying on XML feeds for Google or third-party platforms, periodic testing of the feed URL is therefore a useful part of website maintenance.

  • Case Study 6: Fixing a Kiyoh XML Review Feed After a PHP 8.3 Upgrade

    From Custom XML Feed to Production Review Integration

    A WordPress XML/RSS project can sometimes evolve far beyond the original requirement. This case started with a relatively simple RSS feed problem and eventually became a custom XML integration for displaying Kiyoh customer reviews on a WordPress website.

    The project involved multiple websites, custom XML processing, a WordPress plugin, external review data, and eventually a compatibility issue following a PHP 8.3 upgrade.

    The Initial RSS Feed Problem

    The project originally started in May 2024 when the client needed help creating an RSS feed for jonglogistiek.nl.

    The client had already created an RSS feed using RSS.app, but several important fields were not being generated correctly:

    • Some posts were missing their publishing date.
    • Some posts had no image.
    • The description was incorrect.
    • The client wanted the first paragraph of each post to appear in the feed.
    • A “Lees meer” (Read more) link was required after the introductory text.

    The existing RSS.app feed was provided for reference, and a custom WordPress plugin was developed to generate the required RSS feed.

    Expanding the Requirement: Custom XML

    Shortly afterward, the client asked whether the service was limited to RSS feeds or whether other XML formats could also be created.

    The requirement turned out to be completely different from the original RSS project.

    The client was building a website for Boender Outdoor and wanted to display Kiyoh customer reviews on the website. Kiyoh provided review information through an XML feed, and the client wanted functionality similar to another website that was already displaying reviews using XML data.

    The goal was to make the review information available on:

    boenderoutdoor.nl/reviews

    The client subsequently provided the Kiyoh XML feed URL and confirmed that the requirement was to import the review feed and display it on the website.

    Reading the External XML Feed

    After analyzing the requirement, the technical approach was straightforward:

    1. Retrieve the XML feed from Kiyoh.
    2. Read and process the review data.
    3. Make the review information available inside WordPress.
    4. Display the reviews on the client’s website.
    5. Allow the website’s existing design to control the presentation.

    The client already had a design in mind, so the implementation focused primarily on processing the XML data rather than creating a new review interface from scratch.

    This distinction is important in XML integrations: data processing and front-end presentation are often separate layers. A reliable feed integration should first make sure that the external data can be retrieved and interpreted correctly before worrying about styling.

    A Production Issue Six Months Later

    The project returned in December 2024 when the client reported that the original XML feed on Jonglogistiek.nl had stopped working.

    The timing was critical because the client was preparing to launch an app that depended on the XML feed that same day.

    The client provided access, and the issue was fixed quickly.

    The feed URL remained:

    jonglogistiek.nl/rssfeed.xml

    After confirming that the feed was working again, the client placed an order for the fix.

    This was an example of an important characteristic of XML integrations: the feed URL itself can become part of another application’s infrastructure. Once an app, portal, or external service depends on a feed, keeping that endpoint operational becomes important.

    The PHP 8.3 Compatibility Problem

    The next major issue appeared in August 2025.

    The client upgraded the Boender Outdoor website to PHP 8.3, after which the Kiyoh review integration stopped displaying reviews correctly.

    The client explained that a custom plugin was responsible for retrieving and processing Kiyoh’s XML feed hourly. The plugin provided shortcodes for displaying review statistics and reviews throughout the website.

    Interestingly, some parts of the integration were still working.

    The client reported that the review information at the top of the page was working, while another section displayed:

    “Geen reviews gevonden”

    meaning “No reviews found.”

    The client wanted the review widget on the reviews page restored to its previous working state.

    Diagnosing a Live WordPress Website

    Because the website was live, the repair needed to be handled carefully.

    Access initially became a challenge. The supplied WordPress credentials did not work, and the client encountered login problems as well. The client eventually disabled the firewall and provided working access, allowing the troubleshooting process to continue.

    Once access was available, the focus was narrowed to the existing Kiyoh Review Verwerker plugin.

    The client specifically clarified that:

    • The existing styling was already correct.
    • The plugin was already responsible for the XML functionality.
    • The problem was that reviews were no longer being loaded on the reviews page.
    • The desired presentation should remain unchanged.

    This made the task a targeted compatibility/debugging job rather than a complete rebuild.

    Restoring the Review Display

    The existing review system was investigated and the review display issue was fixed.

    The client had also requested that the reviews remain limited to 25 reviews per page. During the fix, it was confirmed that this limit was already configured, so no additional change was necessary for that requirement.

    The client was informed that the issue had been fixed and was directed to the reviews page for verification.

    The Technical Lesson

    This project demonstrates why upgrading PHP versions on WordPress websites can expose problems in older custom integrations.

    A site can appear to be functioning normally while a particular data-processing component silently stops working. In this case, the website’s styling and surrounding review interface were still present, but the external XML review data was no longer being displayed correctly.

    Rather than rebuilding the entire system, the better approach was to:

    • Identify the failing component.
    • Preserve the existing design.
    • Preserve the existing plugin architecture where possible.
    • Check the external XML source.
    • Investigate the data-processing path.
    • Restore the review output.
    • Verify the existing pagination requirement.

    What This Project Shows

    This project involved several different types of WordPress XML work over time:

    1. Custom RSS feed development

    A standard RSS service was not producing the required post data, so a custom WordPress feed was created.

    2. Custom XML integration

    The requirement expanded into processing an external Kiyoh XML review feed.

    3. WordPress plugin development

    The XML processing was integrated into a custom WordPress plugin with shortcodes for displaying review information.

    4. External data retrieval

    The website depended on XML data supplied by an external review platform.

    5. PHP compatibility troubleshooting

    After a PHP 8.3 upgrade, the review display stopped functioning correctly and required debugging.

    6. Production maintenance

    The issue was resolved on a live website while keeping the existing styling and functionality intact.

    Conclusion

    What began as a simple RSS feed requirement eventually became a longer-term XML integration and maintenance relationship.

    The project illustrates an important principle in WordPress XML development:

    A feed is not just an XML document—it can become a critical data bridge between WordPress, external platforms, widgets, and applications.

    When that bridge stops working because of a PHP upgrade, changes in external XML data, or plugin compatibility issues, the solution requires more than simply checking whether the XML file exists. The complete flow—from external data retrieval to WordPress processing and final display—needs to be examined.

    This case is a good example of how custom XML development can evolve into ongoing integration, troubleshooting, and maintenance work.

  • Case Study 5: XML Job Feed and Predictable Vacancy URLs for RecruitNow

    Category: XML Feed Development
    Industry: Recruitment / Job Listings
    Platform: WordPress
    Integration: RecruitNow / Indeed
    Project Type: Custom XML Feed & Vacancy URL Architecture

    Project Overview

    A recruitment website needed a way to provide its job vacancies through an XML feed while also giving each vacancy a predictable URL based on a unique vacancy ID.

    The requirement was intended to support integration with RecruitNow and job boards such as Indeed, where a predictable vacancy URL could be generated automatically rather than relying on the existing job title-based URL.

    The project involved two connected requirements:

    1. Create a custom XML feed containing vacancy information and a unique vacancy ID.
    2. Create a predictable URL structure using that same ID and redirect it to the actual vacancy page.

    For example:

    https://baantjeuitzendbureau.nl/vacatures/12345

    would redirect to the actual vacancy page:

    https://baantjeuitzendbureau.nl/vacatures/orderpicker-logistiek-medewerker/

    The key idea was to use the same unique identifier in both the XML feed and the redirect URL.

    The Challenge

    The website’s existing vacancy URLs were based primarily on job titles.

    For example:

    /vacatures/orderpicker-logistiek-medewerker/

    The client explained that Indeed required a predictable URL structure containing a vacancy ID. The existing URLs did not provide that ID in a predictable position.

    This created a problem for the external feed integration.

    A job portal should be able to receive a vacancy ID from the XML feed and construct a URL without needing to know the actual title or permalink of the vacancy.

    The proposed structure was:

    /vacatures/{vacancyId}

    For example:

    /vacatures/12345

    The system would then identify the vacancy associated with 12345 and redirect the visitor to the actual vacancy page.

    The client specifically requested this type of URL-and-redirect behavior.

    The Proposed Solution

    The proposed architecture connected the XML feed and redirect system through a common vacancy ID.

    Step 1 — Identify the Vacancy ID

    Each vacancy would have a unique identifier.

    For example:

    vacancyId = 12345

    This ID would become the stable reference for the vacancy.

    Step 2 — Include the ID in the XML Feed

    The XML feed would expose the vacancy ID together with the vacancy information.

    A simplified feed item could look like:

    <vacancy>
    <vacancyId>12345</vacancyId>
    <title>Orderpicker Logistiek Medewerker</title>
    <detailUrl>
        https://baantjeuitzendbureau.nl/vacatures/orderpicker-logistiek-medewerker/
    </detailUrl>
</vacancy>

    The important part is that vacancyId remains consistent with the identifier used by the redirect URL.

    The original project discussion also specified that the same ID should be available in the XML feed so RecruitNow could construct the predictable URL.

    Step 3 — Create the Predictable Vacancy URL

    A separate URL pattern would be made available:

    https://baantjeuitzendbureau.nl/vacatures/{vacancyId}

    For example:

    https://baantjeuitzendbureau.nl/vacatures/12345

    This URL does not contain the job title.

    That makes it predictable and suitable for an external system to construct automatically.

    Step 4 — Redirect to the Actual Vacancy

    When someone visits:

    /vacatures/12345

    the WordPress implementation would:

    1. Extract 12345 from the URL.
    2. Find the corresponding vacancy.
    3. Determine its actual permalink.
    4. Redirect the visitor to that page.

    Conceptually:

    /vacatures/12345
        ↓
Find vacancy ID 12345
        ↓
Find actual vacancy URL
        ↓
/vacatures/orderpicker-logistiek-medewerker/

    This separates the stable external identifier from the changeable public vacancy URL.

    Why This Architecture Is Useful

    Job titles can change.

    For example, a vacancy might initially be published as:

    /vacatures/orderpicker/

    and later become:

    /vacatures/orderpicker-logistiek-medewerker/

    If an external platform depends directly on the title-based URL, such changes can create broken links or require the external feed configuration to be updated.

    A vacancy ID provides a more stable reference:

    /vacatures/12345

    The actual destination can change internally while the external URL remains predictable.

    This is particularly useful when a third-party recruitment platform needs to construct vacancy URLs automatically.

    XML Feed + Redirect Architecture

    The complete concept can be represented as:

                     WordPress Vacancy
                        │
                        ▼
                Unique Vacancy ID
                     12345
                        │
             ┌──────────┴──────────┐
             ▼                     ▼
        XML Job Feed        Predictable URL
        vacancyId=12345     /vacatures/12345
             │                     │
             ▼                     ▼
        RecruitNow /          WordPress
           Indeed             Redirect
                                   │
                                   ▼
                         Actual Vacancy Page

    The XML feed and redirect mechanism therefore use the same identifier as the connection point.

    Initial Project Scope

    The original custom offer covered the setup of the XML feed and redirect URL functionality for RecruitNow. The offer included XML feed creation and redirect URL setup.

    During the discussion, the client confirmed that the XML feed needed to contain vacancy information and that the redirect should work using a unique ID.

    However, before implementation could be completed, the client explained that their original brief had been based on the wrong solution.

    The order was subsequently canceled while the client clarified the revised requirement.

    The client later returned with a more specific requirement: create an additional URL ending in the vacancy ID and redirect that URL to the actual vacancy detail page.

    Project Status

    This case study represents the technical analysis and proposed implementation approach, rather than a completed production deployment.

    The original order was canceled before the implementation was completed because the client’s requirements changed.

    That distinction is important: the case study demonstrates the technical problem, architecture, and proposed solution without claiming that the final system was successfully deployed.

    Key Takeaways

    This project demonstrates an important principle when building XML feeds for third-party job platforms:

    The feed and the destination URL should have a reliable common identifier.

    Instead of depending entirely on a changing job title or permalink, a unique vacancy ID can provide a stable reference between:

    • WordPress vacancy records
    • XML feed items
    • RecruitNow
    • Indeed
    • Predictable external URLs
    • Internal redirects

    A well-designed integration can therefore look like:

    WordPress
   ↓
Vacancy ID
   ├── XML Feed
   └── Predictable URL
          ↓
      Redirect
          ↓
Actual Vacancy Page

    For recruitment websites integrating with external job platforms, this approach can make the feed and URL architecture more predictable, maintainable, and easier for third-party systems to consume.

    Need a Custom XML Job Feed?

    If your WordPress website needs a custom XML, RSS, or job feed for a recruitment portal, job board, ATS, or third-party platform, the feed can be mapped to your existing WordPress vacancy structure and the required external format.

  • Case Study 4: Rebuilding and Troubleshooting a Real Estate & Boat XML Feed After a Domain Migration

    From a Simple “Add Brand” Request to Reliable Marketplace Feed Integration

    Project Overview

    A Danish boat-sales business was migrating from its old domain, dansksejlogmotor.dk, to a new branded domain, ditbaadsalg.dk.

    The domain migration itself was straightforward, but it created an important technical problem: the business relied on XML feeds to distribute its boat listings to external marketplaces, including DBA.dk and ScanBoat.

    After the migration, the feeds were still referencing the old domain and several pieces of structured listing data were not being transferred or displayed correctly.

    What initially started as a small request to add a brand field eventually became a broader XML feed debugging and optimization project involving:

    • Domain migration
    • XML field mapping
    • Product/boat specifications
    • Category mapping
    • Description formatting
    • Image ordering
    • Sold/out-of-stock filtering
    • Price synchronization
    • Scheduled feed updates
    • DBA validation
    • ScanBoat validation
    • Comparison with the previously working feed

    The project demonstrates an important principle in XML feed development: generating valid XML is only one part of the job. The receiving marketplace must also interpret every field correctly.

    1. The Initial Problem

    The business had migrated from:

    dansksejlogmotor.dk

    to:

    ditbaadsalg.dk

    The existing DBA and ScanBoat feeds were still containing URLs from the old domain.

    The first request was therefore to update the feeds so they would work with the new domain.

    Shortly afterward, the client identified another requirement:

    The DBA feed also needed to include the boat’s brand value.

    The client explained that the brand was already entered on the website, but the value was not being included in the XML output.

    At this stage, the task appeared to be a relatively small XML modification.

    2. Adding the Brand Field Exposed Other Feed Problems

    After the brand field was added, the client noticed that some boat descriptions were no longer appearing correctly in the feed.

    For example, the description for a boat such as Saga 26 HT appeared correctly on the website but was being displayed incorrectly in the feed.

    Investigation showed that the existing function responsible for cleaning descriptions for XML output was not working correctly.

    A new description-cleaning approach was therefore required.

    At the same time, another issue appeared: images were being selected in the wrong order.

    Instead of:

    1. Main image
    2. Second image
    3. Third image
    4. etc.

    the feed could contain images in an unexpected order.

    The client specifically requested that the primary product image should always be the first image.

    3. Fixing Image Ordering

    The image logic was updated so that the featured image was placed first in the XML media output.

    The change was subsequently applied to both the DBA and ScanBoat feeds.

    This was important because marketplace feeds are not simply data exports. The order and structure of repeated elements can affect how the receiving platform displays a listing.

    The client later confirmed that the image issue had been resolved.

    4. Sold Listings Were Still Appearing

    Another issue then surfaced.

    The client found several boats that had already been sold—or were hidden drafts—still appearing in the feed.

    The affected listings included:

    • Awi 23
    • Svensk træbåd
    • Princess 415
    • Monterey 254
    • Coaster 600 DC
    • Cranchi Smeraldo

    The website already had a condition intended to exclude products where _stock_status was outofstock.

    This required checking the relationship between the WordPress/WooCommerce product status and the actual feed-generation logic.

    This illustrates another common XML-feed problem: the website can display a listing correctly while the feed-generation rules use different conditions.

    5. Marketplace-Specific Field Mapping

    Once the basic feed issues were addressed, DBA began reporting problems with structured fields.

    Some important information was appearing as:

    • Length: Not specified
    • Engine type: Not specified
    • Seats: Not specified
    • Type: Other

    The client requested that the feed correctly map the boat information to DBA’s expected fields.

    The investigation then moved beyond simply producing XML.

    The receiving platform’s expected field names, formats and category structure became part of the debugging process.

    The client also supplied the old feed as a reference because it had previously worked correctly.

    This provided a valuable baseline:

    Old working feed → New feed → Side-by-side comparison

    6. Reproducing the Old Working Feed

    A particularly important requirement emerged during the project.

    The client wanted the new feed to be as close as possible to the previously working feed from the old domain, while adding the new brand field.

    The requested approach was essentially:

    Make the new feed identical to the old feed, change the sender/domain, add the required fields, and preserve the existing formats.

    The requested structured fields included:

    • category_id
    • engine_included
    • engine_type
    • engine_brand
    • engine_power_hp
    • fuel_type
    • length_feet

    along with the previously added brand field.

    The updated feed was then regenerated with these additional fields.

    7. Category Mapping Became a Critical Issue

    One of the more interesting problems was the DBA category.

    At one point, the client discovered that a value such as:

    <category>37000</category>

    was appearing in the feed and suspected that this was responsible for the incorrect marketplace display.

    The discussion then moved toward whether DBA expected a category value or a category_id value.

    A change to category_id was tested, but DBA subsequently indicated that the system was undergoing a migration to its new Dealer Hub system. The category mapping therefore could not be treated as an isolated XML problem—the receiving platform’s import system was also changing.

    The category change was eventually reverted as requested.

    Lesson

    When troubleshooting marketplace feeds, it is important to distinguish between:

    Feed-side problems

    and

    Marketplace-side import problems.

    A perfectly generated XML feed can still display incorrectly if the marketplace has not reprocessed it, is changing its import system, or is interpreting a field differently.

    8. Feed Updates Were Not Happening Quickly Enough

    Later in the project, the client noticed that:

    • A boat with a new price was still showing its old price in the marketplace.
    • A sold boat was still appearing in the marketplace.

    The client suspected that the feeds were not updating.

    The feed itself needed a more reliable update mechanism.

    A cron job was added so the feed would be refreshed every five minutes.

    This was an important improvement because there are actually two separate stages:

    WordPress data → XML feed → Marketplace import

    Updating the XML feed does not necessarily mean the marketplace has immediately imported the new data.

    That distinction became particularly important during DBA testing.

    9. DBA and ScanBoat Required Different Validation

    The project involved two external platforms:

    • DBA
    • ScanBoat

    Even though both consumed XML feeds, their expectations and processing behavior were not necessarily identical.

    The client reported that ScanBoat was receiving correct information from the old feed but not from the new feed.

    The requirement was to make the new ScanBoat feed reproduce the same data and formatting as the old feed, including decimal formatting.

    The ScanBoat feed therefore required its own validation rather than assuming that fixing the DBA feed would automatically solve the ScanBoat integration.

    10. Description Formatting

    After the marketplace began receiving the updated data, another presentation issue became visible.

    The boat description and technical specifications were appearing as one continuous block of text.

    The client wanted the content separated into readable sections such as:

    Description

    The boat’s main description.

    Dimensions

    • Feet
    • Length
    • Width
    • Draft
    • Displacement
    • Hull type
    • Berths

    Mechanical

    • Engine
    • Batteries
    • Shore power

    Equipment

    • Cockpit equipment
    • Cabin equipment
    • Refrigerator
    • Toilet
    • Other accessories

    The feed output was adjusted so the information would appear with improved separation and readability.

    The client subsequently confirmed that the text had been separated in both feeds.

    11. Testing the Feed Against Real Listings

    Rather than relying only on XML inspection, the project involved checking actual listings across the website and the marketplace.

    For example, a specific boat was compared between:

    Website listing → XML feed → DBA listing

    The client supplied actual listing URLs when an inconsistency appeared, allowing the feed data to be compared with what DBA was displaying.

    This approach is especially important for marketplace integrations.

    A feed can be:

    • syntactically valid,
    • accessible,
    • correctly formatted,

    and still produce an incorrect listing because the receiving platform interprets a field differently.

    12. The Final Testing Stage

    Toward the end of the project, the client reported that ScanBoat was working correctly.

    DBA was also displaying the listings more accurately, although additional marketplace-side processing and testing remained necessary.

    The final testing included new boat listings as well as existing/used boats.

    The project also involved checking whether length in feet was being transmitted correctly. The feed contained the length_feet field, while the client continued checking the behavior on DBA’s side.

    The client eventually confirmed on December 2, 2025:

    “Job is done :-)”

    Technical Challenges Solved

    The project ultimately addressed a much broader set of requirements than the original brand request.

    AreaIssueSolution / Approach
    Domain migrationOld domain URLs remained in feedsUpdated feed output for the new domain
    BrandBrand existed in WordPress but was missing from XMLAdded brand mapping
    DescriptionText was incorrectly formattedUpdated XML-safe description processing
    ImagesPrimary image was not consistently firstFeatured image moved to first position
    Sold listingsOut-of-stock items appeared in feedsChecked feed filtering conditions
    CategoryMarketplace category was interpreted incorrectlyCompared category/category ID requirements
    Boat specificationsLength, engine and other fields missingAdded and mapped structured fields
    PriceUpdated prices were not immediately visibleVerified feed output and marketplace reprocessing
    Feed freshnessChanges were not reflected quicklyAdded a five-minute cron refresh
    ScanBoatNew feed differed from old working feedCompared and adjusted output
    FormattingDescription/specifications appeared as one blockImproved output separation
    ValidationFeed output and marketplace display differedTested actual listings end-to-end

    The Most Important Lesson

    This project demonstrates why XML feed development is more than generating XML syntax.

    A successful marketplace feed has at least four layers:

    1. Source data

    WordPress custom fields, product data, images, prices and status.

    ↓

    2. Feed mapping

    Correct XML tags, values, data types, formatting and filtering.

    ↓

    3. Feed delivery

    A stable, accessible and regularly updated XML endpoint.

    ↓

    4. Marketplace interpretation

    DBA, ScanBoat or another portal imports and maps the feed according to its own specifications.

    A problem can occur at any of these layers.

    That is why simply opening an XML URL in a browser is not always enough to determine whether a feed integration is working correctly.

    Result

    The project evolved from a small feed customization into a complete troubleshooting and synchronization exercise.

    The final work addressed:

    • New-domain feed output
    • Additional structured fields
    • Brand mapping
    • Boat specifications
    • Image ordering
    • Description cleaning
    • Description formatting
    • Listing filtering
    • Category handling
    • Feed refresh scheduling
    • DBA testing
    • ScanBoat testing
    • Comparison with the previous working feed

    Most importantly, the project ended with the client confirming that the job was complete and expressing interest in working together again.

    What This Case Study Shows

    For businesses moving websites, changing domains, adding marketplace integrations, or replacing an existing XML feed, the safest approach is not to build the new feed from scratch without reference.

    Instead:

    1. Preserve the existing working feed structure where possible.
    2. Compare old and new feeds item by item.
    3. Map every important custom field explicitly.
    4. Treat images as structured data, not just URLs.
    5. Filter sold, hidden and unavailable listings correctly.
    6. Validate marketplace-specific categories and field formats.
    7. Understand the difference between feed generation and marketplace import.
    8. Allow for marketplace caching and scheduled imports.
    9. Test real listings from the website through the feed to the marketplace.

    This methodology can significantly reduce the risk of losing or incorrectly displaying listings after a website migration.

    Need a Custom XML Feed?

    If your WordPress website needs a custom XML, RSS or JSON feed for a real estate portal, marketplace, directory, advertising platform or another external system, the important question is not simply:

    “Can you generate XML?”

    The real question is:

    “Can the receiving platform correctly understand and use the data?”

    That is where careful field mapping, feed validation and real-world testing make the difference.

  • 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.

  • Case Study 2: Real Estate Feed Development

    WordPress Custom Fields → XML Mapping → Portal-Ready Feed

    Real estate agencies often manage their property listings in WordPress, but their data needs to be distributed across multiple property portals, each with its own XML structure, field names, location formats, and validation requirements.

    In this project, the goal was to automate that process for two real estate websites and distribute their property portfolios to multiple international property platforms.

    The Challenge

    The client operated two real estate websites:

    • sothebysrealty.me
    • nekretnina.me

    They wanted to automatically export their property portfolio to platforms including:

    • Realting
    • Homes Overseas
    • Tranio
    • A Place in the Sun
    • Prian.ru
    • Realitica
    • Green Acres
    • JamesEdition

    Instead of manually entering or maintaining listings on each portal, the requirement was to create WordPress-based XML feeds that could automatically transform the existing property data into the format expected by each destination platform.

    The initial requirement was relatively straightforward: generate XML feeds from WordPress.

    However, the project quickly demonstrated that real estate feed integration is more than simply converting WordPress posts into XML.

    Different portals required different:

    • Field names
    • XML structures
    • Property types
    • Location values
    • Languages
    • Feature/amenity mappings
    • Publication rules
    • Data formats
    • Business rules

    The source data therefore needed to be mapped and normalized before it could become a reliable portal-ready feed.

    The Solution

    The solution was implemented as a collection of custom WordPress feed integrations.

    The basic architecture was:

    WordPress Property Data → Field Mapping → Data Normalization → XML Generation → Portal-Specific Feed

    Each portal received its own XML output while using the property’s existing information from the WordPress websites.

    For example, a WordPress property could contain information such as:

    • Property type
    • Price
    • Location
    • Bedrooms
    • Bathrooms
    • Features
    • Images
    • Description
    • Property ID
    • Publication information

    The feed logic then transformed these values into the XML structure required by the destination portal.

    1. WordPress Data Extraction

    The first step was extracting the existing property information from the two WordPress websites.

    Rather than requiring the client to maintain a separate database for every portal, the existing WordPress property data remained the primary source.

    This allowed the workflow to remain simple:

    Edit the property once in WordPress → Generate the required XML → Portal consumes the feed.

    The project eventually evolved into a broader multi-portal feed system rather than a single XML export.

    2. Portal-Specific XML Mapping

    Each portal had its own requirements.

    For example, the client supplied the Homes Overseas export specification, while Realting provided an XML sample/template for its import structure. The implementation therefore required studying the destination specifications before creating the mapping.

    The mapping process connected the WordPress property fields to the corresponding portal fields.

    A simplified example:

    WordPress DataPortal XML
    Property ID<property_id>
    Property TypePortal-specific property type
    PricePortal price field
    CityPortal location field
    BedroomsBedroom element
    FeaturesPortal feature elements
    ImagesPortal image elements
    DescriptionPortal description field

    The important point is that this was not a one-to-one XML conversion.

    The same WordPress value could need to be transformed differently depending on the destination portal.

    3. Location Normalization

    Location mapping became one of the important parts of the project.

    The source websites and destination portals did not always use identical city or location names.

    This required custom location mapping so that a WordPress location could be translated into a value recognized by the destination portal.

    The project included additional work specifically for mapping locations where the website’s city names did not match the Green Acres database.

    This illustrates an important lesson from real estate feed development:

    Valid XML does not necessarily mean valid portal data.

    A feed can be technically correct XML and still be rejected or incorrectly categorized by the receiving marketplace if its values do not match the portal’s expected taxonomy.

    4. Property Type Standardization

    Property types also required normalization.

    The source website could use one naming convention while a portal could expect a different set of property categories.

    The project included property-type mapping as part of the broader feed system, and a later website change to the property’s type name even caused multiple existing feeds to require correction.

    This highlighted the importance of making feed integrations resilient to changes in the source WordPress data structure.

    5. Multilingual Feed Support

    The project also required English and Russian feed variations for some portals.

    Separate feed endpoints were created for the different language requirements, with the additional work involving fetching translated data rather than simply duplicating the original XML.

    This meant the feed system had to consider:

    Source language → Translation → Portal-specific XML

    rather than simply:

    Source language → XML

    6. Duplicate Prevention

    Another requirement was preventing the same property from being unnecessarily copied to advertising platforms.

    A custom WordPress function was developed to provide an option on the property edit screen to control whether a property should be copied to another website.

    This introduced a simple but important business rule:

    Property enabled for distribution → Include in feed

    Property disabled for distribution → Exclude from feed

    That gave the client more control over which listings were syndicated.

    7. Feed Validation and Testing

    Generating XML was only one part of the work.

    The feeds also needed to be tested against the destination requirements to make sure:

    • Required fields were present
    • Values were correctly mapped
    • Locations were recognized
    • Property types were accepted
    • Images were included correctly
    • Duplicate listings were controlled
    • Portal-specific XML structures were followed

    The later multi-portal project explicitly included feed validation and testing as part of the implementation scope.

    The Project Expanded Over Time

    What began as a small requirement for two websites and two portals gradually became a much larger feed ecosystem.

    The initial implementation covered:

    2 WordPress websites → 2 destination portals

    It subsequently expanded to additional portals and integrations, including A Place in the Sun, Prian.ru, Realitica, Green Acres, and JamesEdition.
    The work also included merging feeds, additional location mappings, and handling portal-specific limitations.

    For example, during the Green Acres integration, some properties could not be added because the portal did not support the source property’s “price upon request” value.

    This is a good example of why portal integrations often require more than coding alone: some limitations originate from the destination platform itself.

    The Result

    The project evolved from a basic XML export into a reusable multi-portal real estate feed system.

    The resulting workflow allowed property information maintained in WordPress to be transformed into portal-specific XML feeds without manually recreating every listing on every platform.

    The overall process became:

    Manage Property in WordPress

    ↓

    Apply Mapping & Business Rules

    ↓

    Normalize Location / Property Type / Features

    ↓

    Generate Portal-Specific XML

    ↓

    Validate Feed

    ↓

    Publish to Real Estate Portal

    This significantly reduced repetitive data entry and made it possible to distribute listings across multiple real estate marketplaces using automated feeds.

    Key Takeaways

    1. XML generation is only the beginning

    A technically valid XML document is not enough. The receiving portal must also understand the values and structure.

    2. Mapping is the core of real estate feed development

    Property types, locations, features, languages, and other fields often need normalization before they can be exported.

    3. Every portal is different

    A feed designed for one marketplace should not automatically be assumed to work for another.

    4. Source data changes need to be considered

    A change to a WordPress field name or property-type value can affect multiple downstream feeds.

    5. Business rules matter

    Options such as excluding a property, preventing duplicates, handling missing values, or dealing with unsupported pricing models can be just as important as the XML structure itself.

    The Architecture in One Diagram

    WordPress Websites

    sothebysrealty.me + nekretnina.me

    ↓

    Property Data Extraction

    ↓

    Field Mapping

    • Property type
    • Location
    • Price
    • Features
    • Images
    • Languages

    ↓

    Data Normalization

    ↓

    Portal-Specific XML Generator

    ↓

    Validation & Testing

    ↓

    Real Estate Portals

    • Realting
    • Homes Overseas
    • Tranio
    • A Place in the Sun
    • Prian.ru
    • Realitica
    • Green Acres
    • JamesEdition

    Final Outcome

    The project demonstrates how a WordPress website can become the central source of truth for a real estate company’s property portfolio while custom XML integrations handle the differences between external marketplaces.

    Instead of maintaining property data separately on every portal, the workflow becomes:

    Update once in WordPress. Transform automatically. Distribute everywhere.

    That is the real value of a custom real estate XML feed: not just generating XML, but building a reliable bridge between WordPress property data and the specific data requirements of each marketplace.

    Technologies: WordPress · PHP · Custom Plugins · XML · Data Mapping · Feed Validation · Real Estate Portal Integration

  • From WordPress Content to a Portal-Ready XML Feed

    Case Study: WordPress to Custom XML Feed

    The Problem

    The client had a WordPress website containing structured content that needed to be distributed to a third-party platform.

    The standard WordPress RSS feed did not contain all of the information required by the receiving platform. Important custom fields, images, URLs, categories, and other structured data needed to be mapped into a specific XML format.

    The client needed a feed that was:

    • Generated automatically from WordPress
    • Compatible with the receiving platform’s XML specification
    • Able to include custom WordPress fields
    • Properly formatted and encoded
    • Accessible through a dedicated XML URL
    • Reliable enough for regular automated consumption

    The Solution

    We developed a custom WordPress XML feed specifically around the client’s data structure and the requirements of the receiving platform.

    The implementation included:

    1. WordPress Data Mapping

    Relevant WordPress fields were mapped to the required XML elements, including standard post data and custom fields.

    2. Custom XML Structure

    Instead of relying on the default WordPress RSS format, a dedicated XML structure was generated according to the target platform’s requirements.

    3. Image Handling

    Featured images and other required image information were resolved and included in the appropriate XML elements.

    4. Data Formatting

    Dates, URLs, text fields, categories, and other values were formatted correctly for XML output.

    5. XML Validation

    The generated feed was checked for structural and formatting problems to ensure that it could be successfully parsed by the receiving system.

    6. Automatic Generation

    The feed remained connected to the WordPress database, so updates to the website could be reflected in the XML feed without manually creating or editing XML files.

    The Result

    The client received a dedicated, automatically generated XML feed that transformed their existing WordPress content into the format required by the external platform.

    The final solution provided:

    • ✅ Custom WordPress-to-XML data mapping
    • ✅ Support for custom fields
    • ✅ Image support
    • ✅ Structured XML output
    • ✅ Automated feed generation
    • ✅ XML validation
    • ✅ A dedicated feed endpoint

    Key Takeaway

    A standard WordPress RSS feed is not always enough when another platform requires a specific XML structure.

    A custom feed allows the existing WordPress website to become a reliable data source without requiring the client to manually maintain a separate XML file.

    Need a custom XML feed from WordPress?

    Send us your WordPress website, existing feed, or target XML specification and we’ll help determine the right feed structure.

    Before: WordPress posts + ACF/custom fields
    ↓
    Feed Generator: Custom mapping + image resolver + XML builder
    ↓
    After: Validated portal-ready XML feed

Powered by