Implementation Notes

As of Sep 23, 2025, AOPR took over this ET account with a new sitecode of artsofpointrichmond.com. The address bar on EntityThing's site is now "https://www.entrythingy.com/d=artsofpointrichmond.com".​  The new sitecode is "artsofpointrichmond.com"; it is encoded with btoa() into 'YXJ0c29mcG9pbnRyaWNobW9uZC5jb20=' for use in the JavaScript API calls to EntityThingy.

​

The other major change is that the interaction with EntityThingy is handled in code within the WIX HTMLElement above.. We no longer rely on web link to an external site (such as Kenoli's "https://aoprcallforart.site/aoprwix") to act as our ET intermediary (see "Call for Art (old)). 

 

I could not find a way to reference the CSS and JS files that support the HTML within the HTMLElement. WIX seems to block every attempt. So the CSS and JS are embedded within the HTML.

​

For reference, the source JavaScript files are in our sites "Public Code Files".

 

EntityThingy maintains a registry of domains that are allowed to call EntityThingy. At first I thought that we needed to register our website domain  (artsofpointrichmond.com). This alone did not work. WIX mangles our API calls to EntityThingy from within the HTMLElement. A look at the request referrer header reveals that WIX is sending the requests from "https://www-artsofpointrichmond-com.filesusr.com/".

Miles Marino (hello@entitythingy.com) of EntityThingy confirmed and wrote this to me:

​

I added filesusr as an authorized header for you guys. The site domain is still under artsofpointrichmond.com, but now filesusr is authorized to make requests.

And yes, Wix is honestly very very annoying with some of this stuff. I can't tell you the amount of workarounds we have had to figure out because of them!

​