I LOVE data.
However, it’s been quite a few years since I’ve really played in the trenches so
it was super fun (with a dab of exasperation) trying to figure out how to import rich text from Excel into WordPress, whilst preserving the formatting and the ’emoji’s that I sprinkle into my writing.
There were a lot of documentation on the web, but none that addressed some of the errors I was seeing:
- on export of xml map
- data import of date format came out wrong (published date defaulted to 1970)
- illegal characters in handcrafted xml files
Husband wondered why I didn’t just post each of the entries manually.
Because there are about 290 entries since I started doing this properly – that’s why! 😛
And so I persevered, and got my breakthrough after about a day of furrowed brows. Whooop! All 290 entries imported correctly!
(Just so you know, to get the formatting of the output correct, you want to use
for HTML, and not \n for CSV or for XML)
Ok – I couldn’t get the categories or taxonomy to come across but I didn’t care much about that.
When working with technology, sometimes perfect documentation doesn’t exist. It is not feasible to document every single event or permutation of how the technology may or may not function correctly with another system.
Even when the product is mature, you can still experience issues that’s never been seen before.
Acknowledge the risks, and plan some slack for into the project plan.
Set expectations correctly as to how this could play out.
It could be plain sailing (like my migration issue above), or it could be a knotty, gnarly problem that tests the best Technical Architect.
In all cases, communicate, communicate, communicate.
Early and often.
Nobody likes to be in the dark; the more you keep people up to date, the more comfortable they will feel about a situation that they may not have control over.