We have a web app running on CF10. When trying to migrate it to CF2016 update 4, we have a cfajaxproxy that is generating the following error.
Invalid usage of AJAX tag.
Use cfajaximport tag to specify SCRIPTSRC or make sure all ajax controls are inside a single cfform tag that has SCRIPTSRC.
We are running on IIS 8.5 on Windows 2012 R2. The website has a virtual directory /cf_scripts in IIS pointing to D:\ColdFusion2016\cfusion\wwwroot\cf_scripts and I can call any of the scripts directly through the web browser and see the JS.
You will need to show us some code.
Although the code might not have changed during the migration, the way you coded it in CF10 may have been incorrect, CF10 allowed it (as a bug) but they fixed it going forward which means CF2016 is a lot more stricter.
Here is the code snippet of includes. The error appears at the first cfajaxproxy. If I remove the first one, the error moves to the next. I have tried adding a cfajaximport tag before the cfajaxproxy tag and that would generate the same error message.
The CFC's are pretty simple and functions have access set to remote.
|<cfajaxproxy cfc = "members.login.userCheck" jsclassname = "tryLogin">|
|<cfajaxproxy cfc = "emails.compose.autoSaveComp" jsclassname = "compAutoSave">|
|<cfajaxproxy cfc = "members.memberFunctions" jsclassname = "memberFunctions">|
|<cfajaxproxy cfc = "committees.committee_functions" jsclassname = "committeeFunctions">|
|<cfajaxproxy cfc = "forums.forum_functions" jsclassname = "forumFunctions">|
I have a similar problem. Our ColdFusion 2016 server was just upgraded to Update 4 from the previous ColdFusion 2016 update. Before that, the cfajaxproxy worked fine, but now, I'm getting an error that a parameter to my cfc function is required, but not passed in. None of the code has changed at all...just the update was installed.
This is the definition:
<cfajaxproxy cfc="lims.com.qry_userDAO" jsclassname="Users">
Did rolling back resolve your issue? Ours did not seem to correct.
We have not been able to try that yet, but it was working before the update and that is the only thing that has changed on the server.
We contacted Adobe support who told us that there is a Hotfix for Update 4. The Hotfix did resolve my issue with cfajaxproxy. You just have to add a JAR file to the update folder and restart the service. Here is the Bug Tracker link:
Do you recall having to do anything with IIS or tomcat (aside from this hotfix) for setting up ajaxproxy with the cf_scripts folder? I have a virtual directory in IIS that the connector created pointing to it and can recall the JS files via the browser. I would think that with the error being a ColdFusion error and not client side that CF is having trouble finding the scripts. For simplicity and just trying to get it to work, I left the default script source value as it was in the Administrator.
I don't think so. We did have an issue when we went to production because all of our production servers are behind a BigIP server so we had to point the cf_scripts virtual directory to a specific server, but I don't think there was anything special done on Dev. I don't do much with the servers myself though. Maybe the difference is that cfajaxproxy was working for us before the Update, but stopped working after it. It sounds like maybe it was never working for you?
Correct in that it has never worked for us on CF16. Only on CF10 & I am told CF11.
Worked on CF11 all but the latest update
oh and I tried the told us that there is a Hotfix for Update 4 and it did not resolve it. a.s.webster and I are working the same problem
I seem to have the same problem. I just built
I seem to have the same problem. I just set up a new CF 2016 development system and updated it to the latest maintenance. Code that has been working for years with a CFAJAXPROXY now generates that same error message as others have reported. Specifically I get this message: "Invalid usage of AJAX tag.
Use cfajaximport tag to specify SCRIPTSRC or make sure all ajax controls are inside a single cfform tag that has SCRIPTSRC."
It fails on the cfajaximport line below:
<cfwindow closable="true" draggable="true" modal="true" name="NAWindowEdit" resizable="false"
title="Update Name & Address" width="400" height="480" x="400" y="100"
bodyStyle="font-size:12px; font-family: verdana; color: black; text-align: left;"
headerStyle="font-size:13px; font-weight:bold; font-family:Verdana; background-color: ##003399; color: white; text-align:left;">
<cfajaximport tags="cfform, cfwindow, cfdiv" scriptsrc="/CFIDE/scripts">
This seems like rather straightforward coding ... am I doing something wrong that CF 2016 now catches?
You need the patch.
Yes 2016 now catches stuff.
We stopped using the code that was causing the problem.
But can use it.
Been 18 months ... would have to a) find it and b) ask Adobe if it was meant for general release ... I know we paid a small fortune for it and then had them tell us it wasn't a bug. Then what would you call it?
I never found a solution to the issue.
For those having this problem on CF2016, are you by any chance using the installer for it that came out in Dec 2016 (ColdFusion 2016 installer refreshed )? If so, Adobe removed then the yui library that was underlying various CF UI tags. I don't recall if it affected cfajaxproxy, but it could have. The blo post discussed how to add the library back, which one of you folks here might try to see if it helps your issue. (This is also documented at the bottom of the current/CF2018 "deprecated features" doc.)
Again, I am not saying that it WILL fix it, and I realize some here may say they did NOT install that Dec 2016 installer but instead were using the original one from earlier in 2016. Fair enough, on all counts. I'm just sharing this in case it might help--and if it does, we can at least identify here who it DOES help.
Seeing folks scrambling here for 2+ years, and rekindled recently, I just wanted to share it in case it might help.
I don't honestly know which installer I used, but I downloaded the latest version of CF2016 that was available, so I probably used it. I've read some of the docs surrounding things deprecated and I don't see any mention of cfajaxproxy at all so I doubt that a yui library removal could be the issue.
Does anyone know if this cfajaxproxy issue still exists in CF2018? I opted for 2016 only because I like to use stuff that has been in the field for a while. But if 2016 won't work, perhaps 2018 is a better choice for my development environment.
Going to CF2018 won't solve the problem. The YUI library is removed from it by default as well.
Rather than ask folks for more (or presume that the ajaxproxy feature is not affected), you could simply get that yui library (offered on those pages) and put it into the folder indicated (on those pages), and see if things then work. If so, then you have solved your problem.
If it does not help, you could easily delete the folder that you had just extracted. (Do be sure to pay close attention to the docs for where it should be extracted to, to make sure it would do its job. A simple test page doing a cfform and a cfinput type="datefield" would tell you if the yui library is "working" or not.)
Hope that helps.
Oh, and CF2018 has been out for a year now, with 4 updates. It's well past being in the "bleeding edge" category. 🙂 And yes, I can attest to knowing personally of (and working with) dozens of shops running it in production, and there are plenty of signs from discussions here in the forums and the CF portal that a large percentage of folks are running it, without problems unique to it.)
I downloaded the yui package and attempted to extract it into the correct spot. That wasn't 100% obvious because of all the folders in the CF2016 install. I ended up adding it to h:/ColdFusion2016/cfusion/wwwroot/cf_scripts/scripts/. The yui structure also has a lot of folders and subfolders which caused extra folders to be created when unzipped (and they didn't match what I had from CF2016)
Bottom line: it didn't change anything so I have removed it for now.
I'm still looking for ways of getting cfajaxproxy to work ... and am very open to other ideas.
Before you give up on this one, let's just double-check the extraction
process. I have seen it cause heartache before. Even if this may not
ultimately prove helpful for you, perhaps it could be for others reading
First, just simply, when you say you "ended up adding it to
h:/ColdFusion2016/cfusion/wwwroot/cf_scripts/scripts/" and saw the "the yui
stucture", can you recall if you saw that yui as being under the ajax
folder? That's where it should have been put.
Second, just to be clear (and as you may have seen), the zip has folders
which START as wwwroot. So you would have/could have extracted it to right
into your h:/ColdFusion2016/cfusion/ folder-NOT the wwwroot. Maybe you did
a copy paste out of it instead. Anyway, if using a zip extraction
tool/feature, then it should have then prompted you ok its merging THAT
extracted "wwwroot" folder with your EXISTING one (which you referred to).
If folks do NOT see such a prompt, then it's entirely possible that they end
up with it CREATING a new wwwroot folder, UNDER their already EXISTING
wwwroot (so that they see would cfusion/wwwroot/wwwroot, if they looked).
As another test when it's done, if correct you should have had a new "yui"
folder within your coldfusion2016\cfusion\wwwroot\cf_scripts\scripts\ajax
folder, along with a sibling "resources" folder. THAT is primarily what this
process is about restoring: those two folders in that location (for those
who want the YUI-based functionality back that was removed).
And yes, the files added by the zip UNDER that ajax folder (in these two YUI
and resources folders) would have totaled about 300 files.
So if with that new info, you may confirm if things really got setup right,
and yet still do not work as expected for you, then we will have to conclude
that this restore of the YU library is not the solution for your challenge.
In that case, I hope at some point you CAN create a smaller test case that
shows the problem and that any of us might run, such as at the cffiddle.org
I tried to be 100% sure that everything is in the right place and then I tested it again and it still did not work. I suspect that there is something about this that is related to yui though. When I removed the cfajaximport statement, it appeared to fail looking for a file in the yui structure. When I put the yui back it didnt do that, but it left me with a blank area. Sorry if this is confusing--it is for me too.
I will try to create a small sample of the problem.
Right, I thought I had seen a reference to YUI in one of the earlier error messages, which is another reason I pressed on this (though I don’t see it now).
Anyway, I will do so one more time, for your sake. Your note here says you “tried to be 100% sure all was right”, which sounds like you mean you re recollecting that it seemed right. Given that, I will say that if you find you can’t create that simple test (or indeed, before trying), you may want to follow what I said and try it again, and just be 100% sure things look like how I described.
Totally your call, of course. As always, I just want to help.
I've figured out what happened and it comes down to the way I coded the cfajaximport statement. As I indicated above, my statements look like this: <cfajaximport tags="cfform, cfwindow, cfdiv" scriptsrc="/CFIDE/scripts">
I wrote this a few years back and don't know why I had the scriptsrc parameter, but probably found it on sample statements in some documentation. The location of those scripts has now moved, so this was pointing to a non-existent place. Of course I didn't need to include the scriptsrc parameter at all. By removing it, it looks to be working in both CF10 and CF2016.
The second issue to comment on is the yui libraries. I have been getting 2 error messages for missing yui scripts (yahoo-dom-event and animation). As far as I can tell these play no part in any of my programming. But I installed the yui libraries anyway and the error messages went away, with no other effect.