Getting the file to import was only the first part. The records also had to land in the right WordPress fields, keep their dates straight, and pick up location data the site could actually use.
Why I made this
A spreadsheet is a practical place to collect and clean records, but it is not where website visitors need the information. Moving those rows into WordPress one at a time would have been slow, inconsistent, and difficult to repeat.
The import also had to deal with details that disappear in a simplistic CSV demo: custom date handling, PODs fields, and geocoding location data so the records could do something useful after they arrived.
What I did
This was the second version of the script. In the video I walk through the real importer and the edge cases I added after the first pass, including custom dates and geocoded data.
That scope matters. I was not trying to teach every part of WordPress or PHP. I was showing the exact layer of glue a developer needed to understand to turn a spreadsheet-driven process into structured site content.
A note on the archive
This video reflects WordPress, Pods, PHP, and API behavior from 2014. The concepts still matter, but the code should be treated as historical rather than copied into a current production site without review.
I’m keeping it because it shows the whole little problem: data was being managed one way, the website needed it another way, and I built the bridge between them.