I’m trying to get the Newsletter snippet to send an email but get the following message:
« ID passed in request is NaN! »
My snippet call is:
[[Newsletter? &anchor=`68`]]
[!Newsletter? &mode=`doc` &tplFormDoc=`FormDoc` !]
After doing some research found the possible solutions:
1) Are you calling the snippet uncached? ie. using [!filedownload!] -YES
2) Are you using backticks instead of single quotes when calling parameters in the snippet? eg. &downloadCount=`1` -YES
3) have tried calling both [[...]] and [!...!] - YES
4) If you’re using [~[*id*]~] to get the current page for the URL’s and such like, there are occasions (eg. where the tag is embedded deep into a template structure) when it won’t get parsed - resulting in the ’ID passed in request is NaN!’ error.
The solution is to get the page ID by using $modx->makeURL() and outputting to a placeholder in the snippet.
How or where would I insert this code?
...any other ideas?
Hi, I am having the same problem "ID passed in request is NaN!" (trying to get a multi language site by passing a &language parameter in the URL.)
The &id string is validated, and if NOT numeric, it is considered an error. This will include the string after the document ID, and thus the error page is displayed.
Seems a bit strange, but I guess modx does not allow any other parameters in the URL string.
I edited /manager/includes/document.parser.class.inc.php to skip the validation (comment out lines 277 and 278) but obviously that is not the way to go and has some other undesirable results.
Any other suggestions? I might have to go for cookies or global vars, I really need a 100% multilingual site. I’ve been struggling with it for two days now, and how much I like Modx, I will give it one more day ...
I’m running modx 0.9.5, PHP 5.1.4, MySQL 5.0.22 on Apache 2.0.58 (Wamp server)
Ronald
-
MODX Staff
- 10,725 Posts
Both id= and q= are indeed reserved by MODx in query strings. Make sure you name your GET parameters differently than these to avoid conflicts. Otherwise, MODx allows any additional parameters in the URL string; add-on components however, are responsible for handling any of these on their own, so I imagine the problem lies in these add-ons. The only way the validation you commented out would be affecting the outcome is if you added something to the id= parameter without using & after the value, or you are not building your URLs properly with the id= or q= parameters. Without additional information on what is happening, I don’t know what to tell you though...