I hope the "cache stuff" was the felix-cache folder, under cfusion/bin. (And can you confirm, do you have only one instance of cf? The dev edition would support creating more than one, in which case there would be a different folder than cfusion where you should do that.)   Finally, tell us please what value you see in the cf admin "package manager" page under its "settings" feature, specifically what is your "package site url"?  ... View more

Larry, I think you'll find that problem is caused by the fact that the URL opened by CFB (for such a commandbox server) has 2 slashes after the port, such as http://127.0.0.1:9523//CFIDE/administrator/index.cfm. Of course, it should be only 1. And as soon as you set it to be 1, then the images work, as does the login to the admin.   I will add that I have explored the settings available within the CFB server configuration and I don't see what's causing it (or rather, nothing I tried to fix it got it to just show the single slash, which is indeed odd). At least this is a workaround.   And of course, you can just use the commandbox status tray to launch the cf admin instead.   But though for now it seems to ONLY affect the launch of the admin from within CFB and that "servers" view, it does make me wonder if some other feature may be ill-affected by this. Often it's little things like that which people ignore--only to have it bite them later but they don't think of it or they fail to mention it to others trying to help them. 🙂   And granted, the problem does NOT happen with the "other" approach--since it never shows the means to launch the CF admin anyway (from the CFB "servers" view). But I stll have my concerns that that may have still other differences that affect other CFB behavior.   I have my doubts that Adobe is doing much testing with CFB as configured to talk to a commandbox cf instance...and then I suspect most commandbox CF users are not likely using CFB (if they use vscode at all). There are of course the other, older/more-established CFML extensions like kamasamk's and ilya's...and then the Commandbox folks are likley more focused on the Boxlang CFB extension (and how that may be made to play nicely with CFML apps run via boxlang servers instead of CF.)   Interesting times. Anyway, we've laid out plenty for folks to consider, if interested. ... View more

rg, I can confirm that behavior--and I do have a workaround one could consider (if they didn't just rename the folder, as it seems you did).  And I also went ahead and raised a bug report for this.   For details, read on.   1) First, note also that the issue is not just in CF2021 but also CF2023 and cf2025. And it's not new since the latest update (of each of those, in July). It started with the May update (for each of them), which is indeed when the pathfilter.json file was introduced (and that is discussed further in the May update technote for each version.   As you may know, it's a security improvement, requiring one to have permission to edit that file to whitelist paths to which a scheduled task might output its results. There have long been various vulns--long since fixed--where bad guys could CREATE scheduled tasks that were configured to SAVE some file. This is intended to prevent them saving to anyplace other than what you specify in this whitelist).   2) As for the inability to specify a $ for the path, folks who may want to test this on their own (or try different possible solutions) should note first that the pathfilter.json file already has a challenge in that (even on Windows) the path is case-sensitive (including the drive letter) AND we need to use / instead of \ for path separators.   And to that point, someone might wonder if the solution for the need to specify a path with a $ is to escape it. I tried \$ and \\$, and \u0024;, as well as /$ and //$. Maybe SOME expression will work, but not those. 🙂   Finally, another challenge in exploring this is that you do need to restart CF between each attempted change to that file (it does not pick it up when editing a scheduled task).   3) So what's the workaround? Well, in your case it may not be a compelling one, since your path was indeed C:\$myPath\ and you specified C:/$myPath/**.   But those who read about the new pathfilter.json file will learn that that ** pattern rg used at the end means "and any subfolders under it". And so I was going to point out that if your path (for the file to which you wanted to save the output of a task) was something like C:\someotherpath\$myPath\, then you could use C:/someotherpath/**.   And I DID confirm that that WOULD allow you to have a folder UNDER that one that had a $, and you COULD specify that path in the scheduled task.    But in your case, since the $myPath folder was only ONE level down from the root, that would have meant considering use of the path as C:/**,  and of course that would mean ANY folder on the C drive, which would entirely negate the intended security benefit. 🙂   Again, I offer the idea (of specifying the path ABOVE the one with the $ in its name)  in case it may help anyone else.   4) And I hope the elaboration on this whole mechanism may have helped you a bit.  Apologies if you already knew all of it. Again, I write for both the person asking the question and others who may find the thread, which nearly always happens. (Also, now AIs read these forums and we end up contributing here knowledge that even benefits those who do NOT come to these forums.)   Finally, as for the bug report, it's at https://tracker.adobe.com/#/view/CF-4227719. You should add a vote (and comment, if you like), as Adobe does use votes as part of the process of deciding what to address. You would also get notified as Adobe (or others) may respond to it. Indeed, perhaps someone may see it and offer a different workaround, which they may not bother to report here (I did link to this thread there.)   Hope that's helpful. It was indeed an interesting challenge, and I had some spare time to explore with/for you. 🙂 ... View more

That's interesting to hear your conclusion.  And of course, if it worked for you that's all that matters for your need.   But I will say first that no, there should be not inherently be any reason that the attempt to uninstall one CF version should be blocked by another that is running, since the installations are entirely separate (separate folders, separate services, separate CF admin configuration, separate jvm configuration, etc.)   Then again, when people run the CF admin of the new CF version for the first time, the "migration wizard" runs asking if they want the new CF to import admin and config settings from the previous version. In doing THAT, it's possible that some configuration in the NEW instance would "have a pointer" to a folder in the old instance.   One possibility is the listing of customtag folders. As you may know, each CF instance has its own customtags folder by default, named in the CF admin "customtags" page (under "extensions" on the left). If the path to the customtags for the old version was defined in the Admin of the new one (perhaps pulled in via that migration tool), then someone used a custom tag during the life of that new instance, perhaps that customtags folder was now "in use" by the new version.   I've also seen people have CF admin mappings in a new instance that named a folder within the old instance (that's a bit less likely to be a folder IN the old instance, since mappings are usually naming folders OUTSIDE the instance, but it's possible). Again, if someone then called a CFC in the current instance, CF could have looked through those mappings (and customtag paths) to find such a CFC, perhaps then loading it for use in memory.   In either case, it may have been that the uninstall of the old CF vresion was held up by that, such that stopping the new version would "release that hold" on such folders. And we could certainly assert that it would have been nice if SOMETHING would have informed you that it was hung awaiting that. 🙂   I'll add that a benefit of that warning also would have been that you might have then wanted to check in those folders to see if there were any files you wanted to preserve/pull into the corresponding folder of the new instance instead. That's one real negative of the "help" the migration wizard (and CAR file mechanism) offers in pulling in such settings...sometimes people are not really aware that there are files in the old instance that they are somehow unexpectedly still using.   And sadly, you uninstall may or may not have left such remnants behind. You may want to check, if the coldfusion2021 folder still remains. Generally it holds files that CF thinks are not default files (like logs, but could include such customtags, etc.)   Hope that helps. Again, I appreciate this may be a level of detail not necessary for your sitiation. I offer it as much in case someone else finds this thread in the future. 🙂 ... View more

OK, I see now. Thanks for the clarifications (though this has gotten way off-topic for this thread!)   So first, let me clarify that even CF11 had no "edit" button. Instead, it (and even CF2025) do let you click on the NAME of the collection which goes to a page to "manage" the collection. That's not new, not different, and still fails to do what you want (which is more clear from your ticket. FWIW, it only got one other vote, even if you feel confident some comments were removed.)   But I do appreciate better now what you sought...you want to know how the collection was created originally, and I assume you mean you're thinking that whoever created the collection then edited it and used the "path" feature there, to name a folder in which docs of the type (in the type list above it) would be found and indexed. And fair enough that editing it later doesn't "show that was done".   But note that that's not the ONLY way documents get into such a collection: first, one can create a collection using the cfcollection tag/script statement and its action="create" (not using the Admin at all). Second, one can always add new documents using the "index collection" button in that UI (or the cfindex tag/script statement.  And besides naming documents in a folder, that cfindex can even populate the index with data from a database, and so on.)  So it simply wouldn't be possible for the CF Admin to reflect all those changes over time.   But again, I get it: if you did JUST that most simplistic use of creating a collection, and editing it one time to name a folder whose docuemnts should be indexed, you'd wish it would at least show what THAT was. (It would still need to have a way to warn you if OTHER documents were added another way...and I suspect that's part of what they needed to "investigate".)   But I will note, finally, that if you just wished to know "what are the documents in the index, and where did they come from", that CAN be obtained using a simple cfsearch. Or if you prefer not to write even that code, you can use instead the query feature of the solr admin panel (such as at port 8997 for CF2025, available on the machine running the CF addon service as http://localhost:8997/solr). There you can select the desired collection using the "core" UI element on the left, then choose its "query" feature. For a colleciton named test, this url would go right there: http://localhost:8997/solr/#/test/query?q=*:*&q.op=OR&indent=true&useParams=   But as for your hope to have the edit feature of the CF admin collections (choosing the name), no, it still doesn't show what you may have originally chosen the first/only time you edited it and named a directory holding documents to search.    Hope that added context helps someone at least a bit. ... View more

Wolf, first it was the May 2025 updates that are leading to your error.   But the problem is actually more due to a mistaken assumption this change uncovers: using returntype as a querystring/url var was never doing what it seems that code expected. It was NOT "changing" the returntype (like you CAN do with that returnFormat querystring value). Instead, it was simply coming into your CFC method as an "available" argument. CF never used it, and you never used it (didn't define it as an arg), and THAT is why the update has led to this failure.   I'll elaborate, and I can also offer 2 workarounds.   1) First, this would affect those on at least cf2025 update 2, cf2023 update 14, or cf2021 update 20. Those are the updates from May 2025. And it was in those updates that Adobe changed the behavior (adding a protection for us) that required that any arg coming into a remote CFC function/method must be DEFINED as an expected incoming argument.    2) Next, here's the "good news" of an available workaround. In the technotes of each of those is an explanation that if for this problem, showing that you can add a JVM argument for the CF startup which undoes this "protection": -Dcoldfusion.runtime.remotemethod.matchArguments=false FWIW, I discuss that and the whole issue (the changed behavior) in my blog post on the May updates, specifcally in this section on what changed.   3) And you can prove for yourself that what I propose above is what's happening (that the returntype you're passing in whas simply being converted into an incoming argument) by adding to the CFC method either a cfdump of the arguments scope or (if you have the method set to not produce output) you can use cflog/writelog to show the value of  structkeylist(arguments). You will see that the returntype is there--but the returnformat is not. Again, CF honors and uses that returnformat for itself (controlling what format to use to return via http whatever the method returns).    And for good measure, I did that test not only on a later CF version (running with this jvm argument above), but I also did it on CF11 (which you mentioned elsewhere today that you were using in the past. Since CF2018 and earlier don't get updates, they did not get this changed behavior.) Again, it simply showed the returntype being a variable in the arguments scope. (Maybe there was a time in the past when returntype DID do something, but again it was not doing it in at least cf11.)   4) So it would appear that CF has simply been "ignoring" anyone specifying that returntype querystring (unless they did somehow define and use it in the method). And now the recent updates are "protecting" people against ANY such arguments that were previously "ignored" this way (they were simply passed into the method--which could cause them to somehow led to security issues, thus this change by Adobe and identified with a cvv in the APSB for the update. My guess is that this allowed callers to a method to potentially change values of variables--when the coder of the method never expected something "from the outside" could cause that.)   5) Finally, if you didn't want to use the JVM arg (and didn't want to remove the use of the returntype in the querystring--or were concerned about url's "out in the wild" that may come back to your server passing that in), the second workaround for you would be to simply add a definition of that returntype to whatever methods where you want to "allow" it to be passed in.   You could use cfargument for tags or add it in the parens for a script-based function, of course. And you ought to set a default--because you may have requests that call the method WITHOUT passing it in.   6) But really, as I said from the start, all this has simply uncovered a mistaken assumption that that returntype being passed in on the querystring was doing anything. It was not...and with the May updates that's being rejected (just like would happen to ANY argument passed in that was not "expected" by the function).   Security fixes often cause compatibilty issues with old code...which may do things that are surprisingly dangerous. Or in this case, just not doing what we thought. Time marches on, as does CF. You can do one of the workarounds. Just don't let this keep you from updating....because the updates march on as well, and you can't do later ones without getting the "benefit" of these previous ones.   Again, they offer the jvm arg as a way to "just stop the madness", for those who feel they must trade for increased compatibility over the potential security protections.   Hope that helps. ... View more

Good to hear your confirmation of things.   If you (or others) stick with the "other" route and later find something in cf doesn't work as expected (something which could be related to this server configuration), at least you have this second/default option to consider.   Again, you can define more than one "server" pointing to the same instance. You'd just need to edit which one your cfb "project" points to.    Hope all just goes well for you, whichever option you go with.    ... View more

Oh, no worries at all, Mike. I wouldn't have expected you to. 🙂 And I was focusing more on what they said regarding the issue. We shall see.  ... View more

[snip] But, much like my request to be able to actually EDIT a Solr Collection instead of blanking all the fields when the edit button is clicked, I have a feeling that's not going to happen any time, soon. By @WolfShade   Wolf, can you clarify what you mean there? I find that the only operations for (buttons offered to the left of) solr collections are reload, index, optimize, purge, and delete. When you refer to wanting to "edit" a collection, what page are you using---where you refer here to there being "the edit button"? And what would you mean to be editing? Sincere questions.    Or might you be referring instead to a "PDF Service"? Those DO have an "edit" button--but I find it works just fine.  ... View more

Guys, I can share news that I heard from Adobe (earlier today, before Mike's new ticket) that Adobe is aware of the concern and says they plan to address it in the next update. No word on how that will happen, or when it will happen.    For those interested to know more, read on.   I had raised this general concern (about the need to clear the felix-cache) as a tracker ticket last Dec. At that time, I was asking that it be cleared at least after an update: and they did that starting with the March updates. Some are not aware of that, so it's at least some good news.   But sadly (as this thread and others have shown), that wasn't enough as we often needed to clear it again sometimes even AFTER an update, which (like you all have said here) seemed illogical and certainly annoying (and caused a LOT of support issues here in the forums and elsewhere).   Anyway, I bring this up to say that in that other ticket, when this problem remained, I had complained in comments both last month and this month that they needed a better ultimate solution. And I had pressed them about the lack of any reply to that ticket. Then just today did report to me that they planned to address the problem in the next update. Again, there was no more info than that...but I first shared the news in that ticket, and I offer it now here.   I've added a vote to Mike's ticket. I did not bother to offer a link there to my ticket. Again, mine was proposing they clear it after an update. That was done and it was marked closed. Then I pressed them in comments about this ongoing issue. I don't suspect most will find that satisfying to read.   Hopefully Adobe will simply offer a more clear answer in Mike's ticket (or here) about what the planned update will achieve.  And it may well be what was covered by the hotfix which Ravi offered here last week. Sadly, he never replied to my question above asking whether it was just about cfmail or about this broader felix-cache problem.  (And no one from Adobe shared news of that hotfix on my ticket or to me when I pressed about the matter by email.)   Perhaps only time will tell. ... View more

Bkbk, you say "The increase in traffic cannot be the cause of the issue. Scores of users per hour should be no problem at all." As Dave Mason sang, "We Just Disagree", for all the reasons I spelled out.  But I realize it was a long reply (trying to anticipate objections and clarify possible confusions).   More importantly, @BiffJingles , what's the upshot? You've gotten 3 different answers here in 2025, on top of Dave's and mine in 2023. You have the attention of 4 of the most active and experienced troubleshooting folks in these forums. We're wanting to see your problem through to resolution--for you and for the sake of others who may find this thread in the future (ust like you returned to it).   Can you let us know where things stand? And if it's that "your server is still crashing", please clarify what you did or didn't do, among all the things we offered. I would be VERY surprised if the answer is NOT in one of those replies, but it's possible. We need your feedback, to know--and to be able to help you further if needed. ... View more

Thanks for the update. As for why the page worked for bkbk before he discovered the OS change, I'll remind you that it worked for me also if the files were created within the cfusion/wwwroot. He may have tried that first.   Since I noticed you referred to using IIS, that's when I explored further--and had the problem there also.   As for the html page, are you asking why I mentioned it? Or why it would work while a cf page did not (until the OS change). I can't answer. I raised it for the sake of any exploring this further.   Understood on the rest.  ... View more

Folks, I can confirm that the Windows change that bkbk offered does solve this (with respect to serve the request through IIS--I found it was NOT needed if the request is served by the CF web server).   Indeed, I have still more details on all this if it may interest some readers.   To be clear, I've been working along with you both over the weekend, reading every post, creating the files and folders to recreate the problem, and trying every other tweak (all to no avail). I'd not yet written as I'd not yet found a solution. Even though the Windows change will solve the serving of the files via IIS, here's the additional detail:   The problem Dan reports (serving via IIS the CF pages with accented filenames) seems to have started with CF2018 and above. To be clear, I have all CF versions on the same machine, and even WITHOUT making the proposed Windows change, CF2016 and earlier had no trouble serving that file (and later Dan reported he'd previously been working with CF11). I'm doing all these tests on the same Windows 11 machine. Again, the problem is unique to serving the requests through IIS. If one tried to make the request using the CF built-in web server (such as 8500, where by default it expects to find files defined in the cfusion/wwwroot), it worked for me--even on CF2025. Regarding the connectors in the server.xml file, it may help to clarify that the "http" connector in server.xml (protocol="HTTP/1.1") manages that sort of request, while the "ajp" connector  (protocol="AJP/1.3") controls requests made through IIS (or Apache) when that web server connection has been created using the CF web server config (wsconfig) tool. FWIW, if one instead were to setup a forward to the built-in web web server (that 8500), then a request WOULD end up being served by that "http" connector instead. (That's possible in IIS if its ARR feature is implemented and enabled, or its a built-in option in Apache.) Dan, you ask about setting up the keystore. To be clear, that discussion of the keystore only came up when bkbk offered an example of setting up another connector line for https (port="8443"), suggesting to you that it was "missing". FWIW, that connector line is indeed commented out by default in a normal CF install, and it has nothing to do with serving requests through IIS. It would primarily be enabled when one wants to serve the CF admin via https (CF2025 offers a checkbox to enable it in the CF Admin now). Anyway, I'm just pointing out that if your focus is serving your web site's pages via IIS, you don't "need" this connector line (or the keystore configuration for it). Something related to all this: note that if instead you were to setup these files (whose names have accent characters) in the cfusion/wwwroot, you would STILL be able to "reach" them when making a URL request via IIS (even WITHOUT the Windows change). But that's a quirk of the CF web server connector: it's designed so that if the IIS request can't find the file in the IIS site root (or a subfolder, if indicated on the URL), the CF web server connector AUTOMATICALLY looks for the same file (or path/file) in the cfusion/wwwroot. Because the connector and CF get a 404 in trying to find the file in the IIS root, it finds it instead in the cf wwwroot. Of course, that's not a "solution" for this problem--but it's interesting to note. That last point can also complicate testing! If one is not AWARE that it's happening, it could confuse their conclusions (it almost caught me). I changed the code (in that file) to output the CF function getbasetemplatepath(), and for good measure I also outputted the cgi variables script_name, cf_template_path and path_translated. Those confirmed what I proposed here. FWIW, one could also see that if enabling CF debugging output, but I realize Dan may not want to do that in production. And if I then renamed the file in the cfusion/wwroot so that CF could not find it, and that's when it would go back to trying to actually find the file in the IIS site root...and it would fail with a 404, at least until applying this Windows change that BKBK offered. So again, that would seem the "solution"--as far as serving pages via IIS. Though again the fact that it works ok on CF2016 and earlier without that, that does suggest that SOMETHING changed starting with CF2018. And FWIW, I had confirmed that if I instead created an htm file with these french accents, IIS had no trouble serving them (even before the Windows change). And of course htm files are NOT processed by CF (they're not in the list of file extensions defined in the connector's uriworkermap.properties file, to be passed on to CF). That further confirms there's something in CF that changed, leading to all this. And I raise that last point because some people may not WANT to make that OS-level change. They may wonder instead "what changed in CF2018? and why can't we undo that change somehow?" I'm also pretty sure I did undo each change proposed here (in the server.xml, jvm.config, and isapi_redirect.properties), and things still worked as I discuss above (when serving via IIS the files only as found in the IIS root and its folders). And that was fixed only by the OS-level change. so thanks for that, bkbk! Indeed, I realize that Dan will likley be satisfied with just the OS-level change. 🙂   And I'll understand if none of you may opt to reply to this. As I said, I simply wanted to offer the details because I had discerned them over hours of exploration the past couple of days. It seemed a very interesting challenge. I do still wonder if there may be more (and I may be forgetting to mention something else I'd observed), but I'll leave at it this for now.   But again, Dan, it seems you need not worry about the keystore at all. If you guys feel otherwise, do carry on. As always, just trying to help. ... View more

Well, you do seem to be saying you've now tried both. But both should have avoided that error.    To be clear, the empty jvm.config does need to be in the WEB-INF/cfusion/bin (of a Commandbox cf instance folder), to avoid that error when using the default "cf + tomcat".   It's NOT needed if you switch to the "other" option. But then that causes the lack of the couple of menu items I'd mentioned...and it may well lead to other issues. That's what I hoped we may get clarification on, over time.  ... View more

I have new info on these two options.   First, yes, if one does the "other" option as Ravi posed then I can confirm there's no need then of the empty jvm.config I'd mentioned. That said, I've also confirmed that if you go that route, you'll find that when you right-click on the server name (in the servers view of cfb), you will only see the option to edit or delete that server.   But if instead you define the server using the default config choice (of "cf+tomcat bundle"), again that not only WORKS with Commandbox (as long as you add the empty jvm.config) but FWIW you WILL see the other menu items (when you right-click on the server name) one would normally see, including starting/stopping the server, launching the cf admin, etc.  While I appreciate that may seem not too important for a Commandbox server instance (as its status tray ui element offers that and more), I do want to at least note the difference here, in case it may well lead to some other changed behavior within cfb (which I have not yet further explored).   Larry, if you (or others) try one option vs the other, I hope you'll at least consider setting up a server connection using the other approach (it's ok to have more than one pointing to a given CF instance, configured these different ways, I have found). It will be interesting to learn if the "other"option Ravi proposes causes any loss of some capability that the traditional ("cf+tomcat bundle") would have enabled. ... View more

Hmm. This 2011 post makes no mention of docker (since it didn't exist then). If you're going to search the web for posts mentioning high eden space use, to drop in this text, please consider revising your text at least a bit to suit the post--otherwise it reads like a cut/paste promotional piece, if not like a bad AI answer.   That said, I certainly appreciate gceasy and all their related tools, as well as the knowledge they share on their site/s. And Carl's 2011 reply was spot on: we're blessed he's still here helping folks nearly 15 years later. So is FusionReactor, advancing as always.   As for neo rye's helpful answer, we should note that +UseConcMarkSweepGC was deprecated in Java 9 and finally removed in Java 15, so can't be used with cf2023 (which runs on Java 17) and so on. And more could be said about the problem the OP faced, but they never replied and may well have moved on long ago.    Anyway, I thought some perspective might be warranted if others saw this message of yours popping up as a recent reply in the web ui of these cf forums.  ... View more

Ravi, that's interesting to hear. I see we were writing about the same time, so maybe you'd not seen my reply to him.    Are you saying that if one chooses that "other" option, then cfb would NOT look for the jvm.config file? If so, that's helpful to hear. (I'm reading and replying to this on a phone.)   Larry, do let us know if either option works for you. Ravi's is certainly one less step :-), though sadly neither is an obvious one.  ... View more

The problem is not yours. It's a bug in cf, and coincidentally I had reported it last week at the Adobe bug tracker. I hope you'll add a vote, as they give heed to that. This way also, you would be notified if/when they resolve it.  ... View more

Hey, Larry. Long time, no talk. I offer the solution here:   https://community.ortussolutions.com/t/commandbox-visual-studio-code-adobe-coldfusion-builder-extension-with-commandbox/9376/5   Briefly, you'd want to point cfb at the WEB-INF/cfusion/ within that Commandbox server location (the closing slash is important), then most important note that cfb is expecting to find a jvm.config file there (which Commandbox does not require).   Just create an empty jvm.config there, which gets around the cfb problem--without ill-effect on Commandbox. Let us know how it goes.  ... View more

I have a different take than Pete's helpful thoughts, and mine may well prove to be good news for you, Biff, if it proves to match your challenge. But I will say first that the reason CF (and the DB) are going off the rails should not be for a reason that is "magical"--nor is it a "mystery", though it does call for a "tour" through appropriate diagnostics. 🙂 (Nod to the Beatles, for any not getting my quoted references.)   TLDR; First, confirm what OOM errors you find currently in coldfusion-error.log, as they me different than what you mentioned. Second, don't trust GA: your web server logs may show far more traffic than GA is showing (as I will explain). That logging info will also show the user-agent of requests, which traffic may well prove to be mostly from bots and other automated agents. You can easily block any you don't want, using that user-agent header, in IIS using "request filtering" and its simple "rules" feature, which returns a 404 to the requestor. Just be careful that blocking a given user-agent really makes sense. Further, be careful if you also have IIS set to send 404's to CF, as these "blocked" requests would still end up talking to CF. The above approach did prove to be EXACLTY the problem and solution for a client I helped just yesterday. And it's been happening to a lot of people recently (indeed for weeks and months, and longer). It may not be ovbious but it need not remain hidden/mysterious.   I hope folks reading the TLDR won't presume "that's not my problem". That's what the client thought as well, as I will explain. I do think think that if you'll take just a few minutes here to read along and then several minutes to do some assessment of your own diagnostics (which I can help also via screenshare consulting, of course), you may well both FIND your root cause problem and resolve it. 1)  You refer to seeing "gc overhead limit exceeded" indications. That's a good first step.   Was that reported in your app/on-screen, or were you finding it in the CF logs? Either way, do open that coldfusion-error.log, noting first the lines at the top which tell you how far back in time that log goes. Then go to the bottom and do search "up" for that phrase: outofmemory.   Do you find any reporting instead "java heap"? Or perhaps "metaspace"? The former would be CF hitting that heap limit (the "overhead limit" is more a warning in advance of that), while the latter would be about that maxmetaspacesize you referred to in your first note. As Carl noted (and I discuss in the blog post I referred to), most people would do better just to REMOVE that argument. I explain why in the blog post.)   And if instead you are getting "java heap" errors, you could keep "chasing the rabbit" of increasing the heap, which MAY help. But I sense you're wanting to "find and resolve the root cause". You may even be thinking "something's wrong with ColdFusion", but I would suggest otherwise.   2) Indeed, you mentioned in passing (in this note today) that "it's just seen an increase in traffic mostly".   That's in fact where I would have wanted to turn your attention. Indeed that's what I was thinking of when I last replied that first day you wrote (which was 2 years ago rather than 3). I'd added that "If you want to wonder later "why it [the heap increase] was needed", we can discuss that after solving the more important problem, which can be so easily solved."    You never responded again, nor did you mark any reply as an answer, so the discussion lay dormant until now. What I am sharing now is what I would have proposed to share then, if you'd have been interested. And since others may find this thread (especially now that you've revived it), and to help you now that it's happening "again", I'm elaborating.)   3) So you've shared your GA chart, though you only shared a brief window of time in that screenshot (30 mins). Further, it's focused on the count of active users (and "views"), rather than request rates (let alone durations).   Still, we can't tell: is your conclusion that traffic IS up? or perhaps that it doesn't seem to have raised enough to cause problems? If so, I would propose that GA is not the bestplace to be looking for this sort of problem. That has classically under-reported traffic to servers like CF.   Why? Because it's been classically based on the browser receiving the page (and its html) requested and then its executing the little bit of GA js code you would have put into the site. (And of course, it ONLY tracks pages that DO have that little bit of js code.) But the problem may be that your server may be being pounded by traffic that is from automated agents (search engine bots, bad guys grabbing your data, attackers, or more recently AI bots). Those typically do NOT execute any js on the page. They just say "give me the next", and "give me the next".   They could be generating 5x, 10x, or 100x the rate of traffic than regular people--and that rate could have increased for you recently. And I'm not just talking theoretical possibilities: I have helped many people find and resolve this problem many times in recent days, weeks, months, and years.    In fact, just yesterday I helped someone in this same boat. CF was crashing, Task Manager showed it using high CPU and memory--and they'd already tried previously raising the memory on the box and the CF heap , which only forestalled the problem. They didn't have GA, but indeed their contention was that "this is an internal server that no outsider should be hitting". So I asked if they had anything internal beyond Task Manager to monitor things--especially perhaps FusionReactor, or the PMT, or any sort of CF monitor. Like many, they did not. That was not a show-stopper, as I will explain.   (If they did have eitherof thosetools, they are the best at tracking "what's going on in CF, specifically". And FR even creates a great request log tracking every CF request--and ONLY cf requests--including their start time, duration, number of queries, their duration, the requesting IP, its user agent, and several more valuable metrics. Sadly, neither CF itself nor the PMT offers such a log: the PMT stores its data in an ElasticSearch DB and the Tomcat underlying CF can be configured to create a request log.)   4) So instead I'd recommended to them what I now recommend for you: look to your web server logs. You mention being on Windows, so your web server is likely IIS, as it was for the other folks. I guided them to find where those are (which can be found specified within IIS itself, but the default is c:/inetpub/logs/logfiles), and within that is then a folder for each site, named by its IIS "site id" number. Again you can find that from the IIS "sites" section).   They had multiple sites and so multiple folders. We looked at each (rather than presume to know "this site is all we care about". I recommend you do that also.   And within each site's log folder I had them sort the list of files by the date modified. As you may know, IIS logs are stored by day, rolling over at midnight (by default)--though the IIS log lines are tracked as GMT time, so in their case the server was in US Eastern time, so we'd subtract 4 hours from that to find the equivalent to local time in the logs.)   4a) Anyway, the first thing I had them look at was whether any of the recent day's logs were larger than those of previous days or weeks (when there was "no problem"). Even across multiple folders, they didn't see much that stood out--so some might have been inclined to think that a waste of time. But I'll say it's often been VERY clear that SOME days logs were indeed FAR larger than other days, or recent weeks--and it may be in ONE site's folder that was unexpected.   4b) Moving on, and before giving up on the value of these web server logs, I had them open the most recent one. (Again, remember that midnight there would have been 8pm the night before.) I wanted to just take a look to see if we might readily spot some unusual nature of traffic.   I explained first that a real challenge with web server logs (as compared to FR's request logs) is that a web server log will track EVERY request made to it: so if a CF page served up html to the browser, that browser would then process that and make several (perhaps dozens of requests back to the server, such as for js files, css files, image files, and so on), which can make it more challenging to "weed through the logs" to focus only on cf request (and their rate). Further, some CF requests are made without even naming .cfm or .cfc as the file extension.   Still, a "beneficial" side-effect of how bots work is that they tend to again just say "give me this url", then "give me that url"..."I don't care about your silly images or js or css. I just want your content!"   5) And sure enough, on the first screen of their logs (showing about 40 log lines in their editor), it was nothing but cf page request after cf page request. NO requests for images, NO requests for js or css. Just one call for a CF page after another.    And the requests were clearly just going through their site asking for a url that named one product and category after another (of course, other sites might track any possible kind of content). Often sites have lists of categories for display, and within categories lists of items, and features for paging through them. That's like honey to a bear for the bots (or bad guys).  They just trawl through them asking for page after page.   6) Then I pointed out how the IIS logs (and most web server logs) track also the "user-agent" making the request, which might be a "real browser" but often legit bots do identify themselves.   And indeed we saw that on that one page alone that there were 5 different bots in that timeframe of seconds: some from googlebot, bingbot, amazonbot, dotbot, and ahrefsbot.  But the most were in fact from facebook. There were clearly NO requests from any REAL browsers on that screen, nor as we paged down.  And remember, this was 8pm their time--but we found it was true pretty much all the time. I've just as often found chatgpt or other AI bots doing the same thing.   Finally, note also that by default the IIS logs track the duration as the last column of the log--and indeed these were taking several seconds, even dozens when things were bad, as they were in this random log we'd open at their 8pm. Clearly it seemed we'd found the culprit(s).   7) So "what to do"? Some people respond thinking, "we need to block those IP addresses", but others know that's a fools errand. Those bot frameworks (and many bad guys or theives) are sophisticated enough to spread their load over many IPs--which may well change day to day.   And I showed how to block them instead by useragent. But I warned first that if someone in your org WANTS that bot traffic, then you can't "just block it". More on that in a moment.   In their case, though, remember they said this was an internal server/site that they didn't think had ANY incoming outside traffic. (While we could turn our attention to that, addressing things from a firewall or other level, they just needed a quick solution because like you their CF was crashing constantly. We had confirmed in this 20 mins of work and discussion that THIS was their unexpected root cause problem.)   7a) So they was indeed interested in a solution that could block the traffic from THOSE bots (those "user-agents").   And for that I showed how easily we could use IIS to handle that. Either at the site or server level is a "request filtering" feature (among the buttons in the middle of the UI). Openign that shows a UI of tabs, one of this is "rules". Right-click in there to add a new rule. Call it "block bots", and in the header field add "user-agent" (no quotes), then in the values field enter (one per line) even just a portion of the long user agent string--enough to distinguish it. So we did dotbot, ahrefsbot, amazonbot, and facebook. Again, some people may want to think twice about that last one, or about googlebot or bingbot.    As soon as you submit that page the change takes effect. If the bottom of your current IIS log showed a high rate of such traffic, wait a few seconds or minutes and re-open the log and to look for these. BTW, it's not that they would no longer be logged: it's that now they would get a 404 from IIS. The Request Filtering feature literally just rejects the request with a 404: that's what the requester sees, and what the IIS log tracks--and we should see the duration is now just milliseconds, and they should no longer going to CF.   (And of course you can do this sort of blocking by user-agent header in Apache or nginx as well.)   7b) That said, I did warn them (and would warn you and readers) to beware something else: some CF folks modify their IIS "error pages" feature (again at either the site or server level) to have 404's passed to a cf page. While I realize that can offer benefits in some cases, do beware that in this sitation we would NOT be stopping the requests from affecting CF. The 404 handler setup in CF would be blown up with the same rate of requests as before. If you were doing any sort of DB lookup--or worse, tracking the 404 failures as new records--you'd be also burdening your db with this, simply a change in the nature of traffic rather than stopping it.   One could conceivably tweak their cf-based 404 handler to better accomodate this situation. Again in their case it was not a concern, as we confirmed no one had changed their IIS "error pages" setting for 404's to go to a CF page, so we didn't have to deal with this.    (If people wonder why my answers read like blog posts--and my blog posts read like term papers--it's because of these little nuances that are often neglected when simpler answers are offered. Again I'm trying to help you and future readers who find this--and the AI bots who will read it and offer it.)   8) So, all that said, within minutes of making these changes we confirmed first that all the requests from those user agents were indeed getting 404's and taking only milliseconds. Again, they did not have FR to allow us to "see how things were going within CF".   But the most important and wonderful thing for them was that now Task Manager not only no longer showed CF as the top user of CPU, it wasn't even in the top 10! Remember: we had not restarted CF. They were very happy with the result, all achieved within an hour of investigation, explanation, and remediation. (I realize some other situations may not resolve so readily.)   8a) Indeed, though a CF restart was not neccessary in their case, it MAY be in others. If CF was woefully bogged down, you may find that attempting to stop or restart the service may fail. In that case, you could kill the coldfusion.exe from "details" in Task Manager. That's not what you should ALWAYS do, but in a case of CF running out of memory and using all the CPU and unable to shutdown, it's an option. That said, if you just wait a minute after Windows Services reports that it couldn't stop the service, Windows will ITSELF kill the process for you.   Either way, then you will find you can start CF again.   9) The next question will be: do things remain settled?   I'll note that you may need to do another round of assessing your web server logs: there may be new and different bots or bad guys trying to break in. Some may be harder to handle than with this simply "blocking by user agent".    9a) Indeed, I'll add one more thought on blocking that way, especially with regard to the calls from facebook, or linkedin, or perhaps apple and others. Note that those may not be their "search engines" but instead they may reflect the calls made to your server from some resource being shared in your organization's Facebook feed, or that of other folks sharing resources on your site.   In this case, folks scrolling through their posts may pass one with a link to your site, and what's happening is that FB (or linkedin, or whoever) is FETCHING your page for the user, to show it in a PREVIEW window showing what the page WOULD have looked like if browsed.  (It's even a bit more pernicious in that the site's may well fetch your page IN ADVANCE of the user seeing it the post, if they anticipate that the user may soon be scrolling to it.)    Would you really want to block those? Or to have it serve a 404 error as the user's preview of your page? Probably not. (And the social media folks in your org may want to string you up for causing that.)   So what could you do about that? Well, I helped one client facing this problem (and who'd made that mistake in their excitement) to consider that what the preview would have shown was page content that would be so tiny as to really be useless to the user scrolling on their devices. So I proposed they could modifying their CF code to detect when such a request was made (the CF variable cgi.http_user_agent holds the header), in which case they could just return a their company's logo. That may not work for some.   10) So, all that said, and I know it's a lot, I hope you may get to finding what is your root cause, Biff. And please let us know if this sort of diagnostic approach proves helpful or not. Again hopefully you don't need to even spend as much time assessing the diagnostics and resolving the problem as it took for you to read this. Trust me: it took a lot longer for me to write it! Apologies to those who hate elaboration. ... View more

Hey, Ravi. Thanks. Can you clarify if that is a fix for cfmail specifically? Or might it be a fix for the frequent need to delete the felix-cache not only after the update does it (which started with updates earlier this year), but even after we may do it ourselves after that (as some have reported having to do)?  ... View more

Ok, so you're just focused on an inability to import customtag paths, whether a) via the importCFSettings env var (and in the file it points to), or b) even via cfsetup import run within the container, where as a sanity check you'd manually defined it and exported it--and STILL can't import it.   One thing: don't bother with the first path. Again, it's always built-in.  See if that helps. (I'm writing from a phone so can't easily test this for you.)   Second, do you run cf on the Linux host? What if you configure and export a customtag path there? Can you import it there? (Again, try taking out the first one.) If that fails, then this isn't about the cf docker image at all, but about the cfsetup tool. To be clear, all the importCFSettings does is cause that very tool to be called during container startup.   And along this lines, please confirm what is the cf update you're running. You can find it in the admin on both the host and container.   And don't presume the container is 2025 update 3, simply because you use adobecoldfusion/coldfusion2025:latest. Your docker host environment could have cached that for some earlier run of this compose file. Once you've confirmed the version, you could do a `docker pull adobecoldfusion/coldfusion2025:latest`, which WOULD pull down the image for update 3 if you didn't already have it.   I'm just saying we want to be at the latest update for both the host and the image before perhaps reporting this as a bug.   BTW, if you "just need to get this containerization working ASAP", you don't HAVE TO use the importCFSetrings env var. That was added in cf2021.    You could instead export the one customtag in a CAR file (from the host, in the cf admin packaging page), or via code you write to create the custom tag path using the CF admin api. See the cf docs on the cf docker image which shows how to import either of these to be run on container startup. I also show examples of doing each in my "awesome cf compose" repo at github.   Let us know what above does or doesn't work for you.  ... View more

Kenneth, a few questions:   1) in your volume "/webdata/coldfusion", what files do you show there (from the host perspective, I mean)? And have you gone into the container to confirm that the /app folder matches it?    2) And is that a volume mount (a folder on the host) or a true Docker volume? and is the host running Windows or Linux? It can help with me asking some follow-ups.   3) And as for that customtag.json, I don't see that you're referring to it in your compose. You show using only settings.json. Anyway, is that settings.json in both places: the volume and the /app folder within the container? It needs to be in the latter for your importCFSettings to work.    4) And have you confirmed (via the admin within the container) whether whatever you configured using that import did appear? If you may only be "running the app code, which doesn't work as expected", take the time to add the password env var in your compose so you can login to check it out. (I realize you or others may prefer "never to go into the CF Admin within the container". This is for diagnostic purposes, not for manipulating the container.)    5) Finally, as for those values you show being within your customtag.json, where did those come from? a cfsetup export? Was that done from within the container? Why would you be doing that? Don't you want the custom tag paths to be passed in on that import? Do you have customtags defined within that settings.json or not?   You show the customtag.json currently having: {"CUSTOMTAG":{"/WEB-INF/customtags10000":"/opt/coldfusion/cfusion/CustomTags","/WEB-INF/customtags1755704070605":"/app/shared"}} That first one being in /opt/coldfusion/cfusion/Customtags would be the one CF sets up by default, whereas the second one showing /app/shared implies that you plan to put some cf custom tag templates into that /app/shared folder. Do you have such code in that folder? ... View more

To help those who may find this thread (such as if searching brings them here), I want to offer a summary. There was the initial problem reported, then others discovered. It's a very long thread.   First, what Keith reported originally was that as of the July 2025 CF updates (in his case, of cf2023), his use of cfindex would no longer work for .docx files He also reported that uninstalling that July update did NOT resolve the problem For the first couple of days we pursued a couple of lines of consideration, including whether it may be due to an error in the update process But I later confirmed not only that I could recreate the problem, but that it was true also for those on CF2025 and CF2021 who applied the July Update. I also filed an Adobe bug report BKBK then proposed downgrading the search package, which proved to solve the problem of .docx files not being indexed But Keith later reported that he now found also .xlsx files would not index I proposed he downgrade the spreadsheet package. He reported at first that didn't work, but then I reminded him to clear the felix-cache, and then he reported now it worked:  he could now use cfindex to process .docx and .xlsx files, along with the others that had been working   While that takes care of his cfindex problems (and it would work for those who apply the July update and then uninstall it), it still didn't explain why uninstalling the July update left things in this seemingly broken state.   And for that I had (in the midst of all the dozens of replies) also identified and reported here a different problem that expands WELL BEYOND this one matter of cfindex.  Indeed, it can explain many, many problems that some (not all) people have had with recent updates and unusual package management problems.  It has to do with what I've documented is a seeming misconfiguration in the bundlesdependency.json file which is downloaded from Adobe when one performs a CF update (or CF package updates).  For now, check out that message I just linked to. I will eventually create a new bug report (at tracker.adobe.com).   For now, I have updated that other bug report (about this cfindex problem) to also summarize both the workarounds and note this new, different (but related) problem.  So while Keith's original problem seems resolved, for now, this really is just the start of a new journey related to this other issue. I think we will want to create a new thread on that, and let this one close. Maybe I'll do that after I create the Adobe bug report. I'll also do a blog post, as that new info seems important news to share well beyond this one forum thread on cfindex.   But I hope this summary of things helps put a nice bow on this one, for now. If I missed or forgot anything, let me know.  ... View more

Very good to hear. Thanks for the update.    So to be clear, was this still cfindex processing that now failed after the July cf update? (You could have been doing processing with the cf spreadsheet tag or functions.)   I ask this for the sake of others who might find this, and also to update that bug report I'd created (and mentioned here) last week: https://tracker.adobe.com/#/view/CF-4227542   (Update, 50 mins after I asked. I found your previous reply to BKBK where you DID clarify it was cfindex processing that now failed with xlsx files. Sorry, I was working on my phone for my previous replies today: a little more challenging. Anyway, I will go ahead and add that clarification to the bug report.) ... View more

Keith, just downgrade also the spreadsheet package. For more, see my note from Saturday (Aug 16). But I appreciate I offered so much additional info that perhaps that didn't stand as something for you to consider, running on the latest cf update.   What I'd clarified is that those who might do that (apply the July update and then uninstall it) would find that 6 packages remained unexpectedly on that later update, causing problems. I'd also offered a single cfpm command to implement those 6 as appropriate for one who'd done that uninstall of the latest update, thus reverting to the previous one, u14 for cf2023.)    But for your specific situation (now on that latest July cf update, having the bug with cfindex and docx files) , and now that you're finding with xlsx files also, see if just downgrading the spreadsheet package works for your challenge. Do let us know, either way.  ... View more

OK, guys. It's been a long day (working almost entirely on this issue).   1) First, yes BKBK. You are right in that if Keith were to upgrade to u15 and THEN do that downgrade, that will indeed downgrade the search package and should his process to work. Same if he wanted to stay on u14 for some reason and just get the cfindex docs processing working there (but getting updated to u15 is a worthy goal, of course)..   Keith, that's likely your primary goal and so proceed with either of those. You can read on if you like (especially with regard to why the uninstall of u14 still left things amiss), but I don't know if most of it will interest you as much as I hope it will BKB and perhaps others. 🙂   2) So as I alluded to I was focused more on other related things.   One is that he had reverted to u14 (at least he said he had, and his concern was that things still didn't work there). And I think you and he will find that it works also if he does that there. (I actually haven't tested that--though I'd wanted to--as I've been working on the larger problem.) And to be fair, I even said so before your "stop the world" lament, where I agreed that 'downgrading the search package alone may well "work" for what you tested, but it's not the COMPLETE solution'.    And I want to repeat that I DID file the bug report with Adobe to try to get them to figure out why his cfindex of a docx fails with that update to 15 (like it does also for those who update to the latest 2023 or 2021 updates). I want to say first that I totally agree that uninstalling the latest search package IS a workaround for that. You'll want to add that to the bug report, to help others beyond this thread.   3) But thre is a larger problem, which has been my main focus, where in fact the package stayed on u15 even though he uninstalled u15.  As I noted, it affects also MORE than that one package, and more than CF2023 (but also 2025 and 2021). And that is the "exciting" news I'd been wanting to share.   But I also had wanted to help someone like him--who was on 14 and installed 15 and had a problem, then uninstalled. It was your solution and MORE. I'd found that 6 of the CF2023 packages were still on their u15 versions--even after the uninstall of u14. THAT's what caught my attention. As I'd reported earlier today, those 6 (for CF2023) are axis, exchange, saml, search, sharepoint, and  spreadsheet. And while one could manually uninstall each (like you'd had him do that search one), I'd studied the 6 and determined what the previous version of each would be. One could downgrade them via cfpm (to do all 6 at once) cfpm install axis:2023.0.11.330706,exchange:2023.0.11.330706,saml:2023.0.11.330706,search:2023.0.11.330706,sharepoint:2023.0.11.330706,spreadsheet:2023.0.05.330608 (Sadly, there's no simple downgrade optionin CFPM, to just revert from the current version to the earlier one.) Of course, for CF2025 or cf2021 those would be different values, but since Keith was only focused on CF2023 I will leave it at that.   And sorry, but when I wrote last night saying I wasn't sure if what you offered would work, it's just that I had that more complete solution in mind (beyond just what KEith was facing--but I appreciate you were focused more on that.)     4) But moving on to the much larger problem (why the uninstall didn't downgrade them), that was the MOST exciting info I'd found--and what I especially thought you may appreciate.   What I've found is that the problem is in fact a mistake in the bundlesdependency.json file. I'd never studied it closely before yesterday, and as I did, I figured out not only THIS problem (how Keith's uninstall of u15 back to 14 did NOT downgrade those 6 packages), but it ALSO explains MANY of the problems with package management that we've seen her ein the forums--not just with this update but with several over the years.   5) So what's the issue? Well, if you look closely at the json, it's an array with an element for each package and then for that package what its "version" is (like 2023.0.11.330706, for that search version we would hav ehim downgrade to). But then also for MOST (but not ALL) of those package array elements it also indicates a "minimumcoreserverupdaterequired" value. That might be set to 11, such as is the case for that search package he would downgrade to.   But the PROBLEM is that SOME of the packages (these 6 for cf2023 u15, in fact) mistakenly have that that minimumcoreserverupdaterequired value set  ALSO to 11--when they SHOULD be set to 15. And this is in fact that case for that search package, where the one updated for u15 (whose "version" is  2023.0.15.330825) instead ALSO shows its minimumcoreserverupdaterequired=11.   And THAT is why when u15 was uninstalled, CF mistakenly thought, "oh, I can leave that u15 version of search in place, because it works with a core version as low as 11". But in fact that's wrong.  And indeed ANYtime the version of the package exceeds that minimumcoreserverupdaterequired, it's going to lead to this problem.   (And FWIW, it's not ALL of the packages that WERE updated with 15 that have the problem. Several have the CORRECT minimum core value of 15, such as u15's packages for document, scheduler, image, presentation, and others.)   And there are still other examples within that json file where some packages have NO value set for that min core version. Those, too, suffer from this problem (if one is on an older CF update and says to install or update such a package, it won't STOP them even if the package version would be greater than their current core version.) It's really quite a mess. More on finding those in a moment.   6) But there are still other implications of this problem. For instance, as you may know, if you are on one CF version and you tell CF to upgrade a package to a higher version, the CF Admin (or cfpm) should WARN you that doing so would cause CF itself to be upgraded. (Many don't notice that prompt when updating via the Admin UI, as it's just another sentence on the prompt to confirm doing the update.)   The point is that you DO get that prompt for those packages where the min core version value for the package HAS been made equal to the package's version (so 15, for a package whose version is that 2023.0.15.330825 value). But you DON'T get it for these ones where the min core version value is LESS than the package version. And THAT's one way to get in trouble, again whether from the Admin or cfpm.   Besides the 6 wrong for CF2023 update 15, there are 5 for cf2025 u3 (if one is on an earlier update and installs any of those 5 packages, they will get the u3 version unexpectedly) and 7 for cf2021 update 21.   But to be clear, this problem will happen to ANYONE on ANY version earlier that the LATEST CF update, not just one behind the latest. And it's ALSO been a problem for several previous updates.   7) In fact, I created a cf template that anyone can use to perform this very analysis.  It's just a single simple cfm file (broken into functions, for readability).   It lets one specify the CF version they want to test, and what update level they may be on, then it looks at the bundlesdependency.json to determine if nay packages have this problem I'd dicussed above (either the mincore version is LOWER than that package's "version" value or there is NO mincore version for that package).   That code is attached. But since the forums here only let us upload certain file extensions, just change it to a cfm, then save it somewhere that you can run code, and give it a try. Once I hear any feedback I would consider posting it instead to github--so that those interested could track if it changes over time. It's been a very long day, which is another reason I'll hold off on that for now.    8) So this is a bug in the current bundlesdependency.json file, one that Adobe needs to solve. Again, I want to see what you guys think even before I file a bug report. I realize it's been a LOT to read.   Again, in summary, yes for someone in Keith's situation on either cf2023 u15 or 14, he can just downgrade his search package to the u11 version of that. That will get his cfindex code working as expected. But he will still have an updated POI library from some of the OTHER 5 packages suffering this problem in that version. I offered that cfpm install with the corrected versions to help there. (Folks on older updates of the other two CF versions can use this info to figure out what they should do, if they want to automate downgrading their packages which were incorrectly updated, or not correctly downgraded when they uninstalled the latest update.)   But the real crux of the problem is in the mistaken bundlesdepdency.json (which gets downloaded if the "package site" url is set to the default, which for cf2023 is https://www.adobe.com/go/cf2023_packages). And it's happening in all 3 versions, and for updates even before this latest one. This mess REALLY starts to explain why it has been so difficult and confusing to understand some problems people have had. It gets still more confusing when people may DOWNLOAD the json file and might get a different version even once Adobe updates it.   And that's why I really wanted to get this documented here, for us in this thread and eventually to spread the news more widely--and press Adobe for a correction (to all the misconfigurations in all 3 json files). With that, it's beddy bye time. If I've made any mistakes, my apologies. It's been a LOT to juggle, research, organize, distill, write about, etc. Again, sorry for the abruptness earlier.  ... View more

Oh my goodness. ... View more