“No to HTML,” says XML Attributes

Yeah, so I had been laboring over a problem for nearly a year regarding some implementation with the Google Maps API. I have a map marker generated by a WordPress post using the All in One Event Calendar plugin. Essentially I just intercepted the post data from the event and stored what I needed; such as address, date/time, details, in another table for marker use. The data storage was the easy part, but what was giving me the problem was when I would try to copy and paste information into the post body. This was especially evident when there was a link within the post body. Seeing as this wasn’t a horribly derailing issue, I had been working around it. Finally the interruption has annoyed me so much that is was time to fix the problem.

As it turns out, the problem I was having was quite simple. To create markers on the Google map, I first had to pre-load the SQL data to an XML document for a javascript function to read and output the marker information. The problem I was in the XML document creation. After a few hours of bug testing and research, I found that the method in which the SQL data is passed to the XML document does not allow for the storage of HTML.

For example this is what some of my marker data would look like:

<marker name="Dance Camp North" venue="Lost Lake Boy Scout Camp" address="12660 Lost Lake Rd, FAIRBANKS, AK 99701, USA" lat="64.298019" lng="-146.679245"type="Weekend" start="Sep 01, 2012" end="Sep 03, 2012" details="Some stuff in here"/>

The detail attribute was the culprit. The WordPress post would automatically generate whatever HTML it needed to output the content. It looks okay in the SQL database but when it was passed to the XML as an attribute value, it would error fail every time.

A very sad error, indeed. Once I found that the XML attribute value was the problem, the rest was easy. The next steps were just a matter of using the htmlentities() php function to encode the HTML special characters on the XML output so that it would accept the raw ASCII data then decoding the HTML characters back to normal on the javascript output to the browser while the marker detail boxes were created.


Again… easy peasy lemon squeezy.