I understand.
First I would like to say that this contrib is excellent, it will solve my need to have my products displayed in a MODx frontend. Thank you for the work you put into this.
In my case, I don't use language ID 1, so there was no result returned. I didn't try using the language id in the URL as it was not in any of the examples or in the docs. Always pressed for time, this feature escaped me

I didn't look into how this function worked, but I assumed you pulled the default language from the database somewhere and that there was a bug somewhere in that code. As I look closer now, it seems you rely on the URL to provide the language, and then fall back to a preset default if no language is specified in the URL.
It's ok too, but it was hard to guess upon first install and would surely trip up many international users

Changing this default value works well for me, and a note about setting this default value in the docs is all that is needed, imo.
In my case I also had some minor issues with character encoding as the OsC database uses ISO-8859-1 and my CMS uses UTF-8. I had to convert the returned data to UTF-8 and change the charset as well as including the encoding tag in the doctype.
Btw, is there a particular need for the ![CDATA[] tag of the data?
Cheers,
Andreas
Thanks. Sorry about the doc's...I really should add that language id info to it.
As far as character encoding, maybe i can add some kinda flag that the crex_read.php script can pick up...to allow stuff to be spit out in a particular character encoding.
The CDATA is there just to keep stuff from being parsed...when it isnt supposed to (such as HTML text for products or what not)