WP to XML

Category: Case Studies

  • Case Study 21: Converting ClaML XML into a Structured MySQL Database

    Project: ICD-V6 ClaML XML to MySQL Import
    Client: Nick
    Year: May 2020
    Service: XML Parsing, PHP Data Processing, MySQL Database Design
    Delivery: Prioritized, with the initial database structure shared for review

    Project Overview

    The client needed to import a medical classification dataset supplied in ClaML (Classification Markup Language) XML format into a MySQL database.

    Rather than importing a plaintext version of the dataset, the client specifically required processing the structured ClaML XML file. The database schema also needed to be designed from the source data because the client did not have an existing MySQL table structure for this import.

    The resulting database was intended for review and use by the client’s backend development team.

    The Challenge

    The project involved several practical data-processing requirements:

    • Parse structured XML: Process the supplied ClaML XML rather than a plaintext representation.
    • Design the database schema: Develop a MySQL structure based on the source data because no existing schema was provided.
    • Preserve data accuracy: Cross-check the processed data before delivering the database.
    • Meet a tight deadline: The client initially requested completion within one day.
    • Prepare for backend integration: Provide a database backup that the client’s backend developers could review.

    My Approach

    1. Requirements clarification

    I confirmed two essential details with the client before proceeding:

    • Whether an existing MySQL schema was available or needed to be designed.
    • Whether the import covered a single file or multiple files with the same structure.

    The client confirmed that I should create the database structure based on the XML data and that only one file needed to be imported.

    2. XML parsing and database design

    I reviewed the supplied ClaML package and worked on converting its structured data into a MySQL database.

    The database structure was designed around the source data rather than relying on a predefined schema. This established a database backup that could be inspected before the complete deliverable was finalized.

    3. Validation and review

    I shared an initial MySQL backup containing a limited number of records so the client could review the proposed database structure.

    I then continued cross-checking the data and clarified a version-label question. The “v6” suffix in the ZIP filename was an internal file-version label added during processing, not a claim that the dataset represented an older ICD-6 edition.

    4. Delivery coordination

    Because the client needed the work urgently, I prioritized the project and communicated progress throughout the process. I also provided the initial database structure for review while completing the remaining data checks.

    Project Outcome

    The client acknowledged the database backup, confirmed that the filename concern was resolved, and indicated that the file would be sent to the backend development team.

    The client subsequently thanked me for my help with the project.

    The engagement demonstrated the importance of clarifying the source format, designing a suitable database structure, checking imported data, and communicating clearly when working against a short deadline.

    Technical Capabilities Demonstrated

    • XML parsing and structured data extraction
    • ClaML dataset processing
    • MySQL schema design based on source data
    • Data import and accuracy checks
    • Database backup preparation
    • Coordination with a client’s backend development team

    Need to Convert XML Data into MySQL?

    I help businesses and developers transform structured data into usable database formats, including custom XML parsing, PHP-based data processing, MySQL imports, and automated data integration.

    Whether you have a one-time XML import or need a repeatable data-processing solution, I can review your source file, clarify the requirements, and propose a practical implementation plan.

    Website: https://wp2xml.com/

    Contact: contact@wp2xml.com

  • Case Study 20: Building a Courier Booking & Shipping API Integration for WordPress

    From a Simple API Integration to a Complete Online Courier Booking Workflow

    Project Overview

    A courier business approached Ranjit Singh through Fiverr in February 2023 with what initially appeared to be a straightforward requirement:

    Integrate a third-party parcel delivery quotation API into their WordPress website.

    The website was Courier.ie, and the requested API was provided by Norsk Global, a shipping and logistics platform.

    The initial requirement was to connect the API with WordPress/PHP so customers could obtain parcel delivery quotes. However, as the integration progressed, the project expanded considerably.

    What began as an API integration became a broader shipping workflow incorporating:

    • Delivery-service quotation
    • Shipment booking
    • Shipment tracking
    • Customer and consignee information
    • Parcel dimensions and customs information
    • WordPress/PHP integration
    • Payment processing
    • Stripe integration
    • PayPal integration
    • Currency conversion
    • Business markup and fuel surcharge calculations
    • Shipping-label access
    • Carrier/service presentation
    • Address suggestions
    • Production deployment
    • Debugging between the website, API and Norsk support team

    The project became a practical example of how a third-party API integration can evolve into a complete business automation system.

    The Initial Requirement

    The client first contacted Ranjit on February 8, 2023, asking whether he could integrate a third-party parcel delivery quotation API into a WordPress website.

    The first discussion focused on understanding the API, the website and the number of services required. The client provided the website and API documentation and initially expected several API services to be integrated.

    The first service was estimated at $30, with subsequent services priced separately. At that stage, the client indicated that the same implementation could eventually be required for multiple websites.

    The initial scope was therefore relatively simple:

    WordPress website → PHP → Norsk API → shipping information

    But the real complexity appeared once testing began.

    The First Challenge: Working With a Third-Party API

    The first integration was performed on a staging environment.

    Instead of immediately building the complete customer-facing system, the implementation was approached service by service.

    This allowed individual API functions to be tested before being incorporated into the larger workflow.

    The first service became the foundation for the remaining integrations because other API functions depended on the same underlying communication and response handling.

    This staged approach became important when the API credentials and test environment started returning errors.

    For example, the staging API returned an authorization error indicating that the public key was invalid. Test shipment data also produced an unknown error.

    Rather than treating the API documentation as sufficient, the project required real-world testing, API responses, and communication with the provider.

    Working Between the Client and API Provider

    One of the most important aspects of the project was that the developer was not working with only one system.

    There were effectively three parties involved:

    1. Courier.ie — the business website
    2. Ranjit Singh — WordPress/PHP developer
    3. Norsk Global — third-party logistics API provider

    When an API response could not be explained from the website side, the client communicated with Norsk support and passed the responses back to the developer.

    This created an iterative debugging process:

    Website request → Norsk API → API response → developer analysis → provider clarification → revised request → testing

    A particularly important breakthrough occurred when Norsk explained that an attempted UPS shipment was using an export service incorrectly for the selected route. The consignee country and shipment direction did not match the service requirements.

    After this information was applied, the integration began working for that scenario.

    This demonstrated an important lesson:

    Not every API error is a programming error.

    Sometimes the problem is caused by business rules, service restrictions, account configuration or incorrect request parameters.

    Moving Beyond the API

    After the core API functions were working, the project moved from backend integration toward an actual customer-facing booking system.

    The client wanted customers to be able to:

    • Enter shipment information
    • Obtain delivery quotes
    • Select a shipping service
    • Book the shipment
    • Track the shipment
    • Make payment
    • Access the shipment label

    The developer created functional forms for the quote, booking and tracking workflow.

    At this point, the project was no longer simply an API connection.

    It was becoming a complete shipping application inside WordPress.

    Using an Existing Industry Workflow as a Reference

    The client repeatedly referred to ParcelHero as an example of the type of customer experience they wanted.

    The reasoning was practical: ParcelHero was also using Norsk’s services, so its workflow could serve as a useful reference for the customer journey.

    The client asked for the new system to follow a similar pattern, including the presentation of shipping services and booking information.

    This changed the nature of the project.

    It was no longer enough for the API to technically work.

    The output also needed to make sense to an actual customer.

    Expanding the Booking Form

    As real-world testing continued, additional fields were identified as important.

    The booking workflow eventually needed information such as:

    • Collection location
    • Destination location
    • City
    • Postal code
    • Parcel information
    • Shipment details
    • Customs information
    • Export/import reasons
    • HS code
    • Country of origin
    • Consignor information
    • Consignee information

    The client specifically requested additional city and postal-code fields after testing the form.

    Later, the client also emphasized customs-related fields such as country of origin, export/import reasons, parcel description and HS code.

    This is a common pattern in API projects:

    The API documentation describes what the system can do; real users reveal what the interface actually needs.

    Handling Difficult Shipping Routes

    One of the most challenging parts of the project involved international routes.

    Ireland-to-UK and UK-to-Ireland quotations did not always behave as expected.

    At one stage, the system could return services for some routes but not others.

    The developer tested different request parameters, reviewed API responses and worked with the client to obtain additional information from Norsk.

    The client compared the expected results with ParcelHero, which was using the same underlying logistics provider. This gave the project a useful real-world benchmark.

    The debugging process included examining request and response data rather than simply changing code blindly.

    The developer also exposed request/response information during debugging so that the client could share precise technical information with Norsk’s support team.

    This created a much more effective support loop.

    Payment Gateway Integration

    Once the quotation and booking workflow was taking shape, payment became the next major component.

    The client already had access to:

    • Stripe
    • PayPal

    The project therefore expanded to include payment processing.

    The payment module was developed and tested in stages, initially using sandbox credentials. Later, the Stripe integration was moved to the live environment.

    The client also wanted both Stripe and PayPal available rather than relying on a single payment provider.

    This introduced another layer to the workflow:

    Norsk quote → customer price → payment → successful booking → shipment label

    Currency Conversion and Business Pricing

    Another important business requirement emerged during payment integration.

    Norsk’s prices were being returned in GBP, while the courier business operated in Ireland and wanted customers to see prices in EUR.

    Simply displaying the API price was therefore insufficient.

    The system needed to account for:

    1. Supplier/API price
    2. Currency conversion
    3. Business markup
    4. Additional surcharge
    5. Final customer price

    The client specifically requested a mechanism for adding a margin to the supplier prices, as well as accounting for fuel surcharge.

    A currency conversion API was subsequently introduced into the workflow so that GBP-based API prices could be converted for the customer’s EUR-facing experience.

    This was a significant transition from a technical API integration to a business-pricing system.

    The application was no longer simply showing what the carrier charged.

    It was helping the courier business determine what its own customers should pay.

    Shipment Labels and Post-Payment Experience

    The project also needed to handle what happened after payment.

    The client wanted customers to be able to access and print their shipment labels after successfully placing an order.

    A label download link was added to the successful shipment-booking flow.

    This completed an important part of the customer journey:

    Get Quote → Select Service → Enter Shipment Details → Pay → Book Shipment → Access Label

    That is substantially different from a simple “API integration.”

    It is an end-to-end transaction workflow.

    Improving the User Experience

    The client wanted the interface to resemble established courier-booking platforms.

    Several user-experience improvements were therefore introduced during the project:

    • Carrier/service logos
    • Estimated delivery information
    • Additional form fields
    • Address suggestions
    • Payment-provider icons
    • Pricing adjustments
    • Shipment-label access
    • Improved service presentation

    The client specifically requested carrier logos and ETA information because competing services displayed these details. The developer explained that the API response itself did not provide the logos and therefore created a mapping mechanism for displaying them.

    This is another important API-development lesson:

    External APIs often provide data, not the complete presentation layer.

    The application may need to build additional logic around the API to turn raw data into a useful customer experience.

    Debugging in the Real Environment

    The project encountered several issues that required investigation beyond ordinary coding.

    Examples included:

    • Invalid staging credentials
    • API request errors
    • Route/service restrictions
    • Missing services for particular destinations
    • Development-environment differences
    • Payment configuration
    • Currency mismatch
    • Address validation
    • API field requirements
    • Carrier/service presentation
    • Production configuration

    At one point, the client reported that a route returned no services even though the provider’s own system showed available services.

    Instead of assuming the problem was in the form, the developer compared requests and responses and continued working with Norsk’s technical team.

    This approach helped isolate issues that were caused by API-side business rules rather than WordPress code.

    From Staging to Production

    The implementation eventually moved from the development/staging environment toward the production website.

    The plugin was transferred to the production environment, and the quote and tracking pages were made available on the production setup.

    The transition required additional production credentials and configuration, including the live payment environment.

    This is an important distinction in API projects:

    A system that works in a sandbox is not automatically production-ready.

    Production deployment requires another round of testing, credentials, payment configuration, webhooks, pricing and customer-flow verification.

    The Project’s Evolution

    The project can be viewed in several stages.

    Stage 1 — API Proof of Concept

    The original requirement was simple:

    Connect WordPress/PHP to Norsk Global API.

    Stage 2 — Core Shipping Functions

    The integration expanded to include:

    • Quote
    • Booking
    • Tracking

    Four of the planned services were initially implemented, while several less-immediate endpoints were postponed until they were required.

    Stage 3 — Customer Booking Interface

    The API was connected to functional WordPress forms so customers could interact with the system.

    Stage 4 — Business Logic

    The system began handling:

    • Pricing
    • Markup
    • Fuel surcharge
    • Currency conversion
    • Service selection

    Stage 5 — Payments

    Stripe and PayPal were integrated into the workflow.

    Stage 6 — Post-Payment Fulfillment

    The booking process was extended to include shipment-label access.

    Stage 7 — Production

    The system was moved toward the production courier website.

    The Most Important Technical Lesson

    The biggest lesson from this project is that API integration is rarely just about making an HTTP request and displaying the response.

    In a real business environment, the API sits inside a larger system:

    Customer
   ↓
WordPress Form
   ↓
PHP Application Logic
   ↓
Norsk Global API
   ↓
Shipping Services / Pricing
   ↓
Business Pricing Rules
   ↓
Currency Conversion
   ↓
Payment Gateway
   ↓
Shipment Booking
   ↓
Shipping Label
   ↓
Customer

    Every layer introduces its own requirements.

    The API might return a price in one currency.

    The business may sell in another.

    The supplier price may need a markup.

    The customer may need to pay through Stripe or PayPal.

    The booking may require customs information.

    And after payment, the customer may need a printable label.

    A successful integration therefore requires understanding both technical requirements and business requirements.

    What Made This Project Different

    Several characteristics made this project particularly valuable as a development case study.

    1. It involved a real third-party logistics API

    The integration was not built around a simple demonstration API. It required dealing with real shipping-service rules and provider support.

    2. It required iterative debugging

    Several problems could not be solved solely from the original documentation. Request/response analysis and communication with Norsk were essential.

    3. It combined multiple systems

    The project brought together:

    • WordPress
    • PHP
    • Norsk Global API
    • Stripe
    • PayPal
    • Currency conversion
    • Google address suggestions
    • Shipping-label functionality

    4. The requirements evolved

    The project began with an API integration and gradually became a much larger application.

    5. The focus moved from code to business workflow

    The final objective was not simply:

    “Does the API work?”

    It was:

    “Can a customer successfully obtain a quote, choose a service, pay, book a shipment and obtain the necessary shipping information?”

    Project Outcome

    The conversation history documents the development of a working courier-booking workflow and its continued refinement toward production.

    The client ultimately moved from asking whether the API could be integrated to requesting additional functionality, design improvements, payment integration, pricing logic, currency conversion, shipment labels and deployment.

    The client also discussed deploying similar functionality on additional websites, indicating that the underlying integration had value beyond the original implementation.

    The project therefore demonstrated the ability to take a third-party logistics API and progressively transform it into a customized WordPress-based courier booking solution.

    Key Takeaways

    This project demonstrates several principles that are useful for any business considering API integration.

    Start with a working proof of concept

    Instead of building the entire application immediately, the integration was tested service by service.

    Test real API responses

    Documentation provides the structure, but real responses reveal the practical problems.

    Separate API problems from application problems

    A failed API request does not necessarily mean the PHP code is wrong. Service restrictions, account settings, credentials and route rules can all affect results.

    Build around the business workflow

    The API is only one part of the solution.

    Expect requirements to evolve

    Once customers and business owners begin testing the system, additional requirements naturally appear.

    Build for the complete transaction

    For an online courier service, the complete experience includes:

    Quote → Select → Book → Pay → Track → Label

    not merely:

    API → Response

    Conclusion

    What started on February 8, 2023 as a request to integrate a parcel-delivery quotation API became a multi-stage WordPress/PHP logistics application.

    The project required API integration, debugging, third-party coordination, customer-facing forms, shipping logic, payment processing, currency conversion, pricing rules, shipment tracking and label handling.

    Most importantly, the project illustrates the difference between connecting an API and building a business workflow around an API.

    The technical challenge was not simply sending requests to Norsk Global.

    The real challenge was turning those API capabilities into a usable courier-booking experience for customers of Courier.ie.

    That progression—from a small API request to a complete business workflow—is what makes this project a valuable example of practical API integration and WordPress/PHP development.

  • Case study 19: When Code Breaks a Client’s Website: How Programmers Should Communicate During a Production Incident

    The code failed. The communication shouldn’t.

    Every programmer eventually makes a mistake.

    Sometimes it is a small bug that affects one button. Sometimes it is a database query that returns the wrong result. And sometimes, especially when working directly on a live website, a mistake can make an entire website appear broken.

    For a programmer, the technical problem may be understandable: a misplaced function, a bad configuration, an unexpected server response, or a plugin conflict.

    For the client, however, the situation is very different.

    They may see a blank website.

    They may be unable to access WordPress administration.

    They may worry that their data is gone.

    They may wonder whether their business is losing customers.

    And they may immediately ask:

    “What happened?”

    At that moment, technical ability is only half of the job.

    The other half is communication.

    A lesson from a real freelance project

    Early in my freelance work, I experienced a situation that taught me an important lesson about communicating during technical incidents.

    A client hired me to develop a WordPress plugin that would generate an XML feed from their website and synchronize advertisements with another property platform.

    The project was relatively small. The agreed price was $30, with a three-day delivery period and source code included.

    While developing the plugin, I made a mistake in the code. An exit() statement had been placed incorrectly.

    The result was serious: the client’s live WordPress website became inaccessible.

    The client reported that the website was blank and that even the WordPress administration area was not working correctly.

    Naturally, the client’s reaction was emotional.

    From the developer’s perspective, the underlying problem was identifiable and potentially recoverable. From the client’s perspective, however, their website was down.

    That distinction is extremely important.

    Technical reality and client reality are different

    A programmer might think:

    “The plugin is causing the problem. We simply need to disable it.”

    The client might think:

    “My website has disappeared. Is my data safe? Is my business website destroyed? Who is going to pay for this?”

    Both perspectives are understandable.

    The programmer sees the cause.

    The client sees the impact.

    Good communication connects those two perspectives.

    One of the messages I sent at the time was essentially:

    “Your website is ok, we need to remove the plugin.”

    Technically, I was trying to reassure the client.

    But looking back, that was not the best wording.

    If the client is looking at a blank website, telling them that the website is “OK” can sound as though the developer is denying the problem.

    A better approach would have been:

    “I understand that the website is currently blank. I have identified the plugin as the cause. The website files and content should still be intact, and the immediate step is to disable the plugin so we can restore normal access.”

    That message does several things:

    • acknowledges the visible problem;
    • takes responsibility;
    • explains what has been identified;
    • reduces unnecessary panic;
    • provides a recovery direction.

    That is much more effective communication.

    The Five-Step Incident Communication Framework

    When your code causes a problem on a client’s live system, use this simple framework:

    Acknowledge → Own → Explain → Recover → Prevent

    Let’s examine each step.

    1. Acknowledge the problem

    Start with what the client is experiencing.

    Don’t immediately start talking about PHP functions, WordPress hooks, database queries, server configuration, or XML.

    Say:

    “I understand that the website is currently showing a blank page.”

    This confirms that you understand the problem.

    It also prevents the client from feeling ignored.

    During an incident, the first communication should answer:

    “Do you understand what is happening?”

    Only after that should you move into technical details.

    2. Own the mistake

    If your code caused the problem, say so clearly.

    Avoid language such as:

    • “Something happened.”
    • “The server is acting strange.”
    • “Maybe HostGator caused it.”
    • “WordPress is having an issue.”
    • “It could be a plugin conflict.”

    If you already know your code is responsible, don’t hide behind uncertainty.

    A professional message is:

    “I found an issue in the plugin code that is causing the website to stop loading. This is my mistake, and I will focus first on restoring the website.”

    Taking responsibility does not make you look weak.

    In fact, it often establishes trust.

    Clients generally understand that programmers can make mistakes. What damages confidence is when the programmer appears to avoid responsibility.

    3. Explain the technical cause — but in the right amount

    Once the immediate situation is acknowledged, explain the cause.

    In this case, the issue involved an incorrectly placed exit() function inside a new WordPress plugin.

    A technical explanation could be:

    “The plugin contains an exit() call in the wrong execution path. Because the plugin is loaded by WordPress, the statement interrupts normal page execution and results in the blank page.”

    That is useful.

    But the explanation should not become a lecture.

    The client usually doesn’t need to understand PHP execution flow while their website is unavailable.

    Think about the difference between these two messages:

    Too technical:

    “The exit() function is terminating execution before WordPress completes the template lifecycle, probably because the hook is being executed globally.”

    Better:

    “I found an error in the new plugin that stops WordPress from completing the page request. I know where the problem is and am working on disabling the affected component first.”

    The second message communicates the same essential information without overwhelming the client.

    4. Give a recovery plan

    This is perhaps the most important part.

    When a website is down, don’t send ten possible solutions.

    Give the client a clear sequence.

    For example:

    Step 1: Disable the affected plugin.

    Step 2: Confirm that the website loads again.

    Step 3: Inspect and correct the plugin code.

    Step 4: Test the corrected plugin on a safe environment.

    Step 5: Only then reinstall or reactivate it on the live website.

    This is much better than sending a series of disconnected instructions.

    During a production incident, the client wants to know:

    “What happens next?”

    Answer that question explicitly.

    5. Explain how you will prevent a repeat

    After the website is restored, don’t simply say:

    “Fixed.”

    Explain what changed.

    For example:

    “The plugin has been corrected and tested separately. I have also removed the execution path that caused the page to stop loading. Before reactivating it on the live website, I will test the feed generation and WordPress admin functionality.”

    This demonstrates that you are not merely patching the symptom.

    You are addressing the underlying problem.

    Don’t make the client troubleshoot your code

    One of the lessons I learned from this experience is that developers should be careful about transferring technical responsibility to the client during an incident.

    Asking a client to:

    “Remove this folder from wp-content/plugins/”

    may be technically valid.

    But if the client isn’t a developer, they may not be comfortable working inside the hosting filesystem.

    A better approach is to explain why the action is needed:

    “The problem is isolated to the new domaza_xml_feed plugin. Temporarily disabling that plugin should allow WordPress to load normally. If you can provide temporary FTP or hosting access, I can perform the change myself.”

    This is much more reassuring.

    The client understands:

    • what is being changed;
    • why it is being changed;
    • what the expected result is;
    • and who is responsible for the fix.

    Avoid promises like “I’ll fix it in no time”

    When a website is down, developers sometimes try to reassure clients with statements such as:

    “I will fix it in no time.”

    The intention is good.

    The problem is that it creates an unnecessary promise.

    What if the hosting environment introduces another issue?

    What if the backup is unavailable?

    What if the problem is more complicated than initially expected?

    Instead, communicate the next concrete action:

    “My first priority is to restore the website. I will disable the affected plugin and then investigate the code separately.”

    That is confident without making an unrealistic guarantee.

    Never send ten messages when one clear message will do

    Another common mistake during stressful situations is sending message after message.

    For example:

    “Please share hosting access.”

    Then:

    “FTP access would be better.”

    Then:

    “Please ask your hosting provider.”

    Then:

    “Please disable the plugin.”

    Then:

    “Give me one chance.”

    The developer may be trying to help, but to the client it can look like uncertainty.

    A better communication pattern is:

    What happened → What I found → What I will do → What I need from you.

    For example:

    “I identified the new plugin as the cause of the blank page. The issue is related to an execution statement in the plugin code. I need to disable the plugin first to restore the website. If you can provide temporary FTP access, I can do this directly; otherwise, your hosting provider can disable the plugin using the plugin folder name domaza_xml_feed.”

    One message.

    Clear.

    Actionable.

    Professional.

    What about an angry client?

    Clients may write in capital letters.

    They may ask:

    “WHAT DID YOU DO?”

    They may ask:

    “WHO WILL PAY ME?”

    They may blame the developer.

    Your response should not mirror their emotional tone.

    Don’t argue.

    Don’t write:

    “Calm down.”

    Don’t say:

    “It’s not a big problem.”

    Don’t immediately defend yourself.

    Instead:

    “I understand why you’re concerned. The website is currently affected by the plugin I was developing, and I take responsibility for correcting the issue. My immediate priority is to restore the website.”

    This changes the conversation from blame to resolution.

    The importance of testing before touching production

    There is also a technical lesson behind the communication lesson.

    If you are developing a WordPress plugin that can affect the entire website, avoid treating the client’s live website as your development environment whenever possible.

    A safer workflow is:

    Development → Staging → Testing → Backup → Production

    Before activating a new plugin on production:

    • take a backup;
    • test the plugin on staging;
    • verify WordPress admin access;
    • test the homepage;
    • test important custom post types;
    • test database operations;
    • test feed generation;
    • check PHP errors;
    • verify that disabling the plugin restores normal operation.

    For small freelance projects, you may not always have a complete staging environment.

    But you can still create a safer process.

    Even a local WordPress installation or temporary test environment is better than experimenting directly on a client’s live business website.

    Communication is part of programming

    A common misconception among new programmers is that their job is simply to write working code.

    It isn’t.

    Professional software development also involves:

    • understanding requirements;
    • setting expectations;
    • documenting changes;
    • communicating risks;
    • reporting progress;
    • handling failures;
    • explaining technical decisions;
    • and taking responsibility when something goes wrong.

    A developer who writes excellent code but communicates poorly can still create a poor client experience.

    Likewise, a developer who makes an occasional mistake but communicates clearly, takes responsibility, and fixes the problem professionally can maintain a strong working relationship.

    The goal isn’t to become a programmer who never makes mistakes.

    The goal is to become a programmer who knows how to respond when mistakes happen.

    A practical emergency message template

    New programmers and freelancers can keep a template like this available:

    Hi [Client Name],

    I understand that the website is currently affected, and I have identified the issue as coming from the code I recently added.

    I take responsibility for the problem. My first priority is to restore the website, so I recommend temporarily disabling the affected component.

    Once the website is back online, I will investigate and correct the code separately and test the fix before activating it again.

    If you can provide temporary [FTP/hosting/staging] access, I can handle the recovery directly.

    I will keep you updated on the progress and explain the final cause and fix once the issue is resolved.

    Regards,
    [Your Name]

    The template can be adapted depending on the situation.

    The important part is the structure, not the exact wording.

    Five rules every new programmer should remember

    When your code causes a production problem:

    1. Don’t hide the mistake.
    If your code caused it, acknowledge it.

    2. Don’t overwhelm the client with technical details.
    Explain the cause at the level necessary to understand the situation.

    3. Don’t argue about whether the problem is “serious.”
    Focus on restoring the service.

    4. Don’t give multiple conflicting instructions.
    Give one clear recovery plan.

    5. Don’t stop communicating after the fix.
    Explain what happened, what you changed, and how you will reduce the chance of recurrence.

    The bigger lesson

    That 2023 WordPress project was not an example of perfect development.

    It was an example of something more useful: learning from a real production mistake.

    The technical mistake was relatively simple.

    The larger lesson was about professional responsibility.

    When a developer’s code affects a client’s website, the client doesn’t need a perfect programmer.

    They need a programmer who is:

    honest, calm, clear, accountable, and focused on recovery.

    Years of programming experience teach you that bugs are unavoidable.

    Professionalism is demonstrated by what you do next.

    The best developers don’t communicate only when everything works.

    They communicate especially well when something doesn’t work.

    And sometimes, the most valuable lesson from a broken website isn’t found in the code.

    It is found in the conversation that follows.

  • Case Study 18: Building an ADCELL-Compatible Product CSV Feed for Naturfroh

    Project Overview

    In December 2023, I developed a custom CSV product feed for Naturfroh, designed for use with the ADCELL affiliate network.

    The goal was to create a reliable, automatically generated product export that could provide publishers with structured product information while following ADCELL’s technical and data requirements.

    The resulting feed is available at:

    https://www.naturfroh.com

    The CSV export is still working correctly today.

    The Challenge

    For affiliate and product-publishing platforms, simply exporting products to CSV is not enough.

    The feed needs to contain the right product information in a predictable structure so that the receiving platform can process the data correctly.

    The ADCELL requirements specified a range of product attributes, including:

    • Product deeplink
    • Product name
    • Short and long product descriptions
    • Gross and net prices
    • Currency
    • EAN
    • Manufacturer information
    • Product and thumbnail image URLs
    • Product category and category ID
    • Shipping costs
    • Availability
    • Delivery time
    • Product contents
    • Basic price information where legally required

    The ADCELL documentation also identifies mandatory fields that must be present in the product feed.

    This meant the solution had to do more than generate a basic product list—it needed to produce structured data suitable for an external advertising and affiliate ecosystem.

    The Solution

    I developed a dedicated CSV feed endpoint for Naturfroh.

    The feed was designed around ADCELL’s specified CSV structure and technical requirements.

    The documented technical format included:

    • UTF-8 or ISO-8859-15 encoding
    • Semicolon (;) column separator
    • Double quotes as text delimiters
    • Line breaks between records
    • Column headers in the first row
    • Product records beginning from the second row

    The implementation therefore focused on generating consistently structured product data rather than relying on a manually maintained spreadsheet.

    Product Data Mapping

    A key part of the project was mapping the available product information into the fields expected by ADCELL.

    The feed structure accommodates important information such as:

    Product identification

    • Product deeplink
    • Product name
    • EAN
    • Vendor item number
    • Manufacturer
    • Manufacturer article number

    Commercial information

    • Gross price
    • Net price
    • Strike price
    • Currency

    Product presentation

    • Product description
    • Long description
    • Product image
    • Thumbnail
    • Product category
    • Category ID

    Delivery information

    • Shipping costs
    • Availability
    • Delivery time

    The ADCELL specification identifies the core mandatory fields required for a usable product feed.

    Handling Pricing and Currency

    Product pricing is particularly important in an affiliate feed because inconsistent formatting can cause problems during import.

    The ADCELL specification supports several recognized price formats and requires each data row to represent pricing in a single currency.

    The feed therefore needed to provide pricing information in a format that could be reliably interpreted by the receiving system.

    Google Shopping and Basic Price Data

    The ADCELL requirements also cover basic-price information for products where applicable.

    For products sold in the EU, the documentation specifies requirements around basic price, unit and content information, including supported units such as:

    • kg
    • l
    • cm
    • m
    • sqm
    • ct

    It also specifies formatting rules for numerical values and unit combinations.

    This is an important consideration when developing product feeds intended for use beyond a simple affiliate product list.

    Result

    The completed feed provided Naturfroh with a dedicated, machine-readable product export for ADCELL.

    Feed:
    https://www.naturfroh.com

    Development: December 2023

    Current status: The CSV export is still working correctly.

    The long-term availability of the feed demonstrates the value of creating a dedicated automated export rather than preparing a one-time CSV file manually.

    Technical Takeaway

    This project is a good example of how a relatively simple-looking CSV requirement can involve several layers of technical work:

    Product database → Data mapping → Formatting → Validation → CSV generation → External platform consumption

    A successful product feed needs to consider both the source data and the requirements of the receiving platform.

    In this case, the implementation was built around ADCELL’s documented requirements for product fields, CSV structure, pricing and product information.

    What I Can Build

    I can develop similar custom product feeds and data integrations for:

    • Affiliate networks
    • Product comparison websites
    • Advertising platforms
    • Google Shopping
    • Marketplaces
    • Real-estate portals
    • XML/RSS consumers
    • Custom APIs
    • CSV/Excel imports
    • Automated data synchronization

    If your platform has a specific feed specification, I can map the existing website or database data to the required format and create an automated feed endpoint.

    Need a custom XML, RSS, CSV or API integration?

    Contact me at contact@wp2xml.com.

  • Case Study 17: WordPress Job Board to Indeed XML Feed: A Real-World Integration Case Study

    How a WordPress Job Board Was Prepared for Automated Job Distribution to Indeed

    Introduction

    Job boards depend on accurate, structured data to distribute job listings across external recruitment platforms. When a website uses WordPress and a job-board plugin, connecting that data to a third-party platform such as Indeed can require more than simply generating an XML file.

    This case study documents a real-world WordPress XML feed project for KA Resources, where the requirement was to make job listings from a WordPress/WPJobBoard website available to Indeed through an XML feed.

    The project evolved from an initial feed requirement into an iterative integration and validation process involving XML structure, HTML formatting, escaped entities, industry information, and salary formatting.

    The Challenge

    The client initially approached us with a straightforward requirement:

    Export jobs from a WordPress website using WPJobBoard to Indeed through an XML/RSS feed.

    The important distinction was that the client needed an export feed, not an import solution.

    At the beginning of the project, the first step was therefore not to immediately build a custom XML generator. We investigated the existing WordPress setup and discovered that WPJobBoard already provided an XML job feed intended for Indeed.

    This changed the implementation approach.

    Instead of unnecessarily rebuilding functionality that was already available, the focus shifted toward identifying the correct feed, making sure it contained the required information, and preparing it for Indeed’s review process.

    The Solution

    1. Understanding the Existing WordPress Environment

    The website was running WordPress with WPJobBoard as the job-management system.

    The first technical objective was to determine how job information was already stored and exposed by the plugin.

    Once the existing Indeed-compatible feed was identified, the client was provided with the feed URL that could be submitted to Indeed.

    A key benefit of this approach was automation: when new jobs were added to WPJobBoard, they would automatically become available through the feed rather than requiring a separate manual export process.

    2. Preparing the Feed for Indeed Review

    Generating a feed was only the first stage.

    The client submitted the feed to Indeed, after which Indeed returned feedback regarding the formatting of job data.

    The first validation response identified issues involving:

    • Escaped HTML entities
    • Job descriptions lacking the expected HTML formatting
    • Proper handling of characters such as &, <, >, and quotes
    • Appropriate HTML tags within job descriptions

    The feed was then reviewed against the requirements provided by Indeed.

    This illustrates an important point about third-party XML integrations:

    A feed can be technically valid XML and still require additional changes to satisfy the destination platform’s data and formatting rules.

    3. Handling HTML Entities and Job Description Formatting

    The job descriptions needed to be represented correctly inside the XML feed.

    The implementation was reviewed to ensure that HTML entities were appropriately represented and that supported HTML formatting could be preserved.

    The feed was subsequently updated and the client was asked to resubmit it to Indeed for another review.

    This iterative process allowed the implementation to be tested against the actual requirements of the receiving platform rather than relying only on generic XML validation.

    4. Adding the Industry Field

    Indeed subsequently requested additional information that could help its system understand the job listings.

    One of the requested changes was an industry field.

    The feed was updated to include the industry information, demonstrating how a custom feed can be extended when the receiving platform introduces or identifies additional data requirements.

    5. Handling Salary Data Correctly

    Salary information presented another important integration detail.

    Indeed required salary information to include both the amount and the applicable period, such as:

    • per hour
    • per week
    • per month
    • per year

    The project revealed an important distinction between feed-generation logic and source data quality.

    The XML feed was collecting salary information from the website’s database. Where the underlying job record did not contain the salary in the format expected by Indeed, changing the XML structure alone would not necessarily solve the underlying data problem.

    For example, the project identified a job where the salary was stored as descriptive text rather than in the structured format expected by Indeed.

    The solution therefore involved explaining how the job’s source salary information needed to be entered correctly so that the feed could automatically reflect the structured data.

    This is an important principle in feed development:

    The quality of an XML feed depends not only on the code generating it, but also on the quality and structure of the underlying data.

    Technical Overview

    Website Environment

    • CMS: WordPress
    • Job Management: WPJobBoard
    • Output: XML job feed
    • Destination Platform: Indeed
    • Integration Type: Automated job-feed distribution
    • Data Source: WordPress/WPJobBoard database

    Feed Requirements Addressed

    The project involved working with:

    • Job listing data
    • Job descriptions
    • HTML formatting
    • XML entity escaping
    • Industry information
    • Salary information
    • Salary periods
    • Feed submission and validation
    • Iterative corrections based on destination-platform feedback

    The implementation was not treated as a one-time XML export. It was handled as an integration where the feed needed to satisfy the requirements of the external platform.

    Challenge → Solution → Outcome

    ChallengeSolutionOutcome
    Jobs needed to be exported from WordPress to IndeedIdentified the existing WPJobBoard Indeed XML feedAn automated feed was made available for submission
    New jobs needed to appear without manual exportsUsed the dynamically generated feedNew WPJobBoard jobs could be reflected automatically
    Indeed reported formatting issuesReviewed HTML entities and job-description formattingFeed formatting was adjusted according to the reported requirements
    Additional industry information was requestedAdded an industry fieldFeed structure was extended to provide the requested information
    Salary data did not consistently match Indeed’s required formatInvestigated the source salary fields and explained the required structured inputSource data could be maintained in a format that the feed could transmit correctly
    Integration required external validationWorked through Indeed’s feedback and resubmission processThe project progressed through an iterative platform-validation workflow

    Beyond the Initial XML Feed

    The project also demonstrates how solving one technical integration problem can establish the foundation for longer-term development work.

    After the Indeed feed project, the client approached us with additional WordPress requirements involving ACF and WP All Import. Later, the client also discussed other WordPress/PHP development work.
    Interestingly, not every requested task was accepted.

    When a later ACF/WP All Import requirement fell outside the current technical scope, the limitation was communicated honestly rather than promising work that could not confidently be delivered. The client explicitly appreciated that honesty.

    That approach remains important in technical consulting: understand the requirement, verify the available solution, communicate limitations clearly, and focus on delivering reliable work.

    Key Lessons From the Project

    1. Investigate Before Building

    Not every integration requires a completely custom solution.

    The first step was to investigate WPJobBoard’s existing capabilities. This avoided rebuilding functionality that was already available.

    2. XML Validity Is Only One Part of Feed Development

    A feed may be structurally valid XML but still fail a receiving platform’s requirements.

    Destination-specific requirements can include:

    • Data formatting
    • HTML handling
    • Required fields
    • Character escaping
    • Salary structures
    • Content conventions

    3. Source Data Matters

    A feed generator can only reliably transmit the data available to it.

    If salary, location, category, or other information is stored incorrectly in the source system, the feed may faithfully reproduce that problem.

    4. Third-Party Validation Is Part of the Development Process

    External platforms may provide feedback that cannot be fully anticipated during the initial implementation.

    A robust integration process therefore includes:

    Build → Submit → Validate → Analyze → Adjust → Resubmit

    5. Honest Technical Communication Builds Trust

    The project also demonstrated that technical consulting is not simply about saying “yes” to every request.

    When a later requirement was outside the current scope of expertise, it was communicated directly. The client responded positively to that transparency.

    Conclusion

    This WordPress-to-Indeed project began with a simple requirement: make WordPress job listings available to Indeed through XML.

    What initially appeared to be a straightforward feed-generation task became a practical integration exercise involving:

    WordPress + WPJobBoard + XML + HTML formatting + structured salary data + industry mapping + third-party validation.

    The project highlights why professional XML feed development is more than producing an XML document. The feed must accurately represent the source data, follow the destination platform’s specifications, and remain maintainable as new content is added.

    At wp2xml, we work with businesses that need structured data from WordPress websites to reach external platforms through XML, RSS, JSON feeds, APIs, and custom integrations.

    Need a Custom XML or RSS Feed for Your WordPress Website?

    Whether you need to connect a real-estate website, job board, directory, e-commerce site, or custom WordPress application to a third-party platform, we can help analyze your existing data structure and develop a feed around the actual requirements.

    Have a WordPress website that needs a custom XML, RSS, or JSON feed?

    Visit wp2xml.com to discuss your requirements and build a feed designed for your target platform.

  • Case Study 16: Custom RSS Feed for Selective Chapter Publishing

    Client

    Wookedin2gaming

    Project Type

    Custom RSS/XML Feed Development for WordPress

    Destination Platform

    NovelUpdates

    Overview

    Wookedin2gaming approached us with a challenging RSS feed requirement for a manga and novel publishing website.

    The website used a purchased custom WordPress theme, and its content was not created through WordPress’s traditional “Add Post” or “Add Page” interface. Instead, the site used a specialized content structure for publishing manga and novel chapters.

    The key requirement was to create an RSS feed that would expose only publicly available/unlocked chapters, allowing NovelUpdates to automatically discover and publish eligible updates.

    The project therefore required more than a standard WordPress RSS feed. The feed needed to understand the site’s custom publishing structure and distinguish between content that was available to readers and chapters that were still locked.

    The Challenge

    The website had two primary types of chapters:

    • Unlocked chapters — available to readers without payment.
    • Locked/advanced chapters — initially restricted and available only after payment or until they became free through the site’s release mechanism.

    The client wanted the RSS feed to include chapters appearing in the site’s “NEWLY BREWED” section, while excluding chapters that remained locked.

    This was particularly important because NovelUpdates needed a feed containing only eligible chapters rather than relying on the website’s page source.

    The project also had to account for the site’s custom content structure rather than relying on standard WordPress post queries.

    The Solution

    We developed a custom RSS feed specifically around the website’s existing publishing workflow.

    The feed was configured to work with the site’s custom manga/novel content and expose the appropriate unlocked chapters for external consumption.

    A major part of the implementation involved handling publication dates correctly so that newly released chapters appeared in the expected order.

    The feed was subsequently adjusted to use the site’s GMT+8 timezone, matching the client’s server and staff publishing environment.

    Handling Same-Time Chapter Releases

    During testing, an important edge case was identified.

    Multiple chapters could be released at exactly the same date and time. When several items had identical timestamps, the feed could not reliably establish which chapter should appear first.

    For example, two consecutive chapters could initially have:

    • Chapter 111 — 10:00:00
    • Chapter 112 — 10:00:00

    The feed required a distinct chronological order.

    The solution was to use a one-second difference when multiple chapters were released at the same time:

    • Chapter 111 — 10:00:00
    • Chapter 112 — 10:00:01

    This helped maintain the intended descending order within the RSS feed.

    The client subsequently implemented different release timings for chapters, and reported that the feed worked better.

    Timezone and Publication Date Handling

    The project also uncovered a timezone-related issue involving chapters without a scheduled release date.

    The feed script was using GMT in certain situations, which could cause the publication time in the RSS feed to differ from the site’s actual publishing environment.

    The implementation was updated to properly account for the client’s GMT+8 timezone.

    Later investigation identified that chapters without a scheduled date were being processed using GMT time. The plugin/script was updated and a revised version was supplied to the client.

    Feed Reliability Improvements

    After the initial implementation, the project continued through several rounds of testing and troubleshooting.

    The client reported situations where:

    • Some newly released chapters did not appear at the expected position.
    • Multiple chapters released simultaneously were not consistently picked up by the destination platform.
    • The feed occasionally became unavailable.
    • The feed was loading significantly more historical releases than necessary.

    The feed was subsequently optimized to limit the number of loaded items.

    The client reported that the feed had been loading more than 2,000 releases, even though the destination service only needed the latest updates.

    We changed the feed configuration to return a maximum of 100 items, reducing unnecessary processing and keeping the feed focused on recent releases.

    Results

    The project evolved from a simple RSS requirement into a custom feed solution designed around a specialized publishing workflow.

    Key improvements included:

    • Custom RSS feed for a non-standard WordPress content structure
    • Filtering of eligible/unlocked chapters
    • Integration for automatic discovery by NovelUpdates
    • Correct handling of the client’s GMT+8 publishing timezone
    • Improved chronological ordering of chapters
    • Handling of chapters released at the same time
    • Troubleshooting of feed availability issues
    • Reduction of feed items from 2,000+ to 100
    • Ongoing maintenance and troubleshooting as new edge cases appeared

    The client continued using the feed and returned for additional adjustments as the publishing workflow evolved.

    Technical Takeaway

    This project demonstrates why a standard WordPress RSS feed is not always sufficient for websites using custom themes, custom post structures, or specialized publishing workflows.

    A reliable XML/RSS integration may require understanding:

    • How content is stored
    • How publication status is determined
    • How scheduled and unscheduled content is handled
    • How timezone conversion affects pubDate
    • How identical timestamps affect item ordering
    • How many records should be loaded
    • How the destination platform consumes and processes the feed

    For websites that need to send selected WordPress content to an external platform, a custom XML/RSS feed can provide much more precise control than a default WordPress feed.

    Destination

    The completed feed was designed for automatic content discovery by NovelUpdates, allowing eligible chapter updates to be supplied through a dedicated RSS feed.

    NovelUpdates

    WP2XML Services

    This case is an example of the type of custom XML/RSS work we handle at WP2XML.

    If your WordPress website uses a custom theme, custom content structure, membership system, scheduled publishing, or specific filtering rules, a standard RSS feed may not meet your requirements.

    We can develop a custom XML, RSS, or JSON feed based on your exact feed specification and integration requirements.

  • Case Study 15: Google Product Review Feed for Kiierr: Building a Google-Ready XML Feed

    Overview

    In July 2024, we worked with Kiierr to develop a custom Google Product Review Feed for its e-commerce product and review data.

    The project involved transforming product review information into a structured XML feed based on Google’s Product Review Feed requirements, making the data easier to consume through Google’s product-review ecosystem.

    This project is a good example of how a standard website’s product and review information can be converted into a specialized XML format for an external platform.

    The Challenge

    Product review data is often stored inside an e-commerce website in a format designed primarily for website visitors.

    External platforms such as Google require that information to follow a specific XML structure, with appropriate elements and relationships between products, reviews, ratings, and other relevant information.

    For Kiierr, the requirement was to create a dedicated feed that could present its product review information in a format aligned with Google’s Product Review Feed specification.

    The key challenge was not simply generating XML. The feed needed to:

    • Follow the required XML structure.
    • Represent product and review information correctly.
    • Map the website’s available data to the appropriate feed fields.
    • Handle product identifiers and review-related information.
    • Produce a consistent, machine-readable feed.
    • Provide a dedicated feed URL that could be accessed by the external platform.

    Our Solution

    We developed a custom Google Product Review Feed specifically for Kiierr.

    Rather than relying on a generic XML export, the feed was structured around Google’s product-review feed requirements.

    The development process included:

    1. Data Mapping

    The available product and review information was mapped to the corresponding fields required by the Google Product Review Feed format.

    This included determining which information should be used for products, reviews, ratings, and other associated data.

    2. Custom XML Generation

    A dedicated XML feed was created to generate the required product-review structure dynamically.

    This allowed the feed to represent the website’s review data in a structured format rather than requiring manual XML updates.

    3. Product and Review Relationships

    Product information and associated reviews need to be represented consistently so that an external system can understand which review belongs to which product.

    The feed therefore handled the relationship between product information and its corresponding review data.

    4. Structured Feed Output

    The final implementation provided a dedicated XML feed endpoint that could be accessed independently from the main website.

    This makes it possible for an external service to retrieve the structured data without depending on the presentation layer of the website.

    Why Custom Feed Development Matters

    A product-review feed is different from a conventional RSS feed.

    An RSS feed primarily communicates content updates such as articles, posts, or other published items. A product-review feed has a much more specific data model and must represent information such as:

    • Products
    • Product identifiers
    • Reviews
    • Review authors
    • Ratings
    • Review content
    • Review dates
    • Product/review relationships

    For this reason, simply exporting website content as XML is not enough.

    The important part of this type of project is understanding the target platform’s specification and building the feed around that specification.

    Project Outcome

    The Kiierr project resulted in a dedicated Google Product Review Feed developed in July 2024.

    The project demonstrated our ability to work with specialized XML specifications, map e-commerce data into structured formats, and develop custom feeds for third-party platforms.

    It also forms part of our broader experience developing XML, RSS, product, real-estate, job, API, and other custom data feeds.

    Our Experience With Custom XML Feeds

    Over the years, we have worked on a wide range of feed-related projects, including:

    • Google product and review feeds
    • RSS feeds
    • Real-estate XML feeds
    • Job-board XML feeds
    • API-to-XML integrations
    • XML-to-CSV conversions
    • XML-to-XML transformations
    • Custom PHP feed generators
    • Product data feeds
    • Marketplace and portal feeds

    Each project requires a slightly different approach because the destination platform often has its own XML structure, required fields, validation rules, and data-mapping requirements.

    Need a Custom Product or XML Feed?

    If your website already contains product, review, property, job, or other structured data but you need it exported into a specific XML format, we can develop a custom feed around your requirements.

    We can help with:

    Custom XML Feeds • Google Feeds • RSS Feeds • Product Feeds • API-to-XML • XML-to-XML • XML Troubleshooting

    Have an existing feed that is no longer working correctly? We can also investigate and fix XML structure, data mapping, validation, and feed-generation issues.

    Contact us to discuss your feed requirements.

  • Case Study 14: Custom Real Estate XML Feed Integration for International Property Portals

    Client Background

    A real estate agency based in Spain approached us with approximately 750 property listings stored in a multi-agency property database. The agency already had several XML feeds but needed a new custom XML feed for a German property portal with very specific technical and data requirements.

    The client wanted the feed to follow the receiving portal’s specification precisely rather than simply exporting the existing property data.

    The Challenge

    The main challenge was creating an XML feed that could:

    • Retrieve property information from the client’s external property database.
    • Transform the available property data into the required XML structure.
    • Follow the receiving portal’s exact XML specification.
    • Support the required API-based delivery process.
    • Work independently of the client’s main website.

    The client initially shared their website, but after reviewing the requirements, it became clear that the primary data source was Resales Online, rather than the agency’s WordPress or website content.

    This distinction was important because the XML feed did not need to be generated from the agency’s public website. Instead, the integration needed to work with the external property database and the receiving portal’s requirements.

    Understanding the Data Source

    The client’s properties were maintained through the Resales Online network. The project therefore required access to the relevant property database rather than relying on the agency website.

    After discussing the architecture with the client, we clarified that website access was not required. Instead, the integration would use the appropriate database/API access and a hosting environment capable of running the PHP-based conversion script.

    This helped simplify the implementation and avoided unnecessary changes to the client’s existing website.

    German Portal Requirements

    The receiving company provided technical specifications explaining that XML data had to be submitted through its REST API according to its own XML specification.

    The client supplied the technical documentation for the receiving platform, including information about its Import API and Import/Export API. The receiving company also indicated that use of the API was subject to its own service requirements and fees.

    This meant the project was more than simply producing an XML file. The feed had to be structured and prepared in a way compatible with the receiving portal’s technical requirements.

    API Access and Authentication

    During implementation, it became necessary to obtain the appropriate API credentials from the receiving platform.

    The client was guided through the API permission process and the relevant self-service area for generating API credentials. When necessary, the client also provided account access so that the integration work could proceed.

    Authentication was coordinated with the client because the platform required additional verification during login. The client provided the required verification code while the integration was being configured.

    Solution

    The solution involved creating a custom XML feed specifically around the client’s external property data source and the receiving portal’s requirements.

    The general workflow was:

    Property Database → Data Retrieval → Data Transformation → Custom XML Generation → Portal/API Delivery

    The approach avoided modifying the client’s main website and instead focused on the data integration layer.

    A separate PHP-capable hosting environment could be used to execute the conversion script, allowing the feed generation process to operate independently from the public-facing real estate website.

    Project Delivery

    The initial project was agreed including revisions and source code.

    The project required communication between three important components:

    1. The real estate agency
    2. The external property database
    3. The receiving property portal

    This made requirement clarification particularly important before development began.

    A Successful Follow-Up Project

    The relationship continued after the initial XML feed project.

    On March 17, 2025, the same client returned with another requirement: an XML feed for Idealista, a Spanish property portal.

    The client explained that Idealista required the feed developer to contact them directly to obtain the XML feed specification. The new feed was expected to be similar to the previous integration, but without the translation requirement used for the earlier project.

    A new custom offer was subsequently prepared to develop a feed specifically for Idealista.

    Key Lessons

    1. Identify the Real Data Source First

    A client’s public website is not necessarily the source of truth for a real estate feed.

    In this project, the agency website was initially shared, but the actual property data was maintained through an external property database. Identifying this early prevented unnecessary work on the website.

    2. Follow the Receiving Portal’s Specification

    International property portals often have their own XML structures, required fields, APIs and authentication procedures.

    A successful feed therefore needs to be designed around the destination portal’s specification, not simply around the source database.

    3. Separate Website Development From Feed Integration

    Because the client’s website was not required for this integration, the feed could be developed independently.

    This approach reduces the risk of interfering with an existing production website and makes the integration easier to maintain.

    4. API Credentials Are Part of the Integration

    XML feed development can involve more than XML formatting. When the destination platform requires REST API submission, authentication and API permissions also become part of the technical workflow.

    5. A Good Integration Can Lead to Repeat Business

    One of the strongest outcomes of this project was the client’s return for another XML feed shortly afterward.

    The second request for an Idealista feed demonstrated that successful completion of one portal integration can establish trust for additional international property-feed projects.

    Conclusion

    This project demonstrates how a custom real estate XML feed can connect an external property database with an international property portal without requiring changes to the agency’s main website.

    The key was understanding the actual data source, reviewing the destination portal’s technical requirements, obtaining the necessary API access, and building the feed around the receiving platform’s specification.

    The subsequent Idealista request from the same client further demonstrated the value of delivering a practical, portal-specific XML integration that can be extended to additional property platforms.

    Project Type: Custom Real Estate XML Feed
    Data Source: External Multi-Agency Property Database
    Integration: Custom XML + REST API
    Follow-Up: Idealista XML Feed Integration

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

Powered by CookieAdmin