Why doesn't Railo read the 'customtag' path like CFMX 6.1 does? - coldfusion

I am trying to migrate from CFMX 6.1 to Railo 3.1.
I have custom tags in this directory for CFMX 6.1
C:\cfusionmx\customtags\myapp
I copied the directory to
{railo-web}/customtags/
and added this mapping through the Railo administrator and also enabled the "Search subdirectories" setting.
I get this error the moment I try to access a page that calls anything from this directory:
invalid component definition, can't find mycfc
My Railo installation is deployed through GlassFish v3.
I see the error the moment this script is loaded:
<cfscript>
mycfcinstance = createobject("component","mycfc");
</cfscript>
In the legacy app that I try to migrate, a lot of CFCs have been stored in CFMX 6.1's customtag path.

First of all, Railo simply does not support search for CFC's inside the Custom Tag directory. Seems that it will, one day.
Second, it looks like small misunderstanding the meaning of the Railo CFC-based custom tags, which you can manage using that "Archives & Resources > Custom Tags" page in Admin. You can find more about it in Railo's blog, for example in these posts: part one and two.
As for the Railo workaround for this legacy app, I couldn't find the way to imitate desired behaviour.
It can be inappropriate, but maybe you will end with batch-replacing
createobject("component","components.
with
createobject("component","
and creating mapping in the Application.cfc or Admin.
So, if you want to put cfc somewhere in the application root.
this.mappings["/components"] = getDirectoryFromPath(getCurrentTemplatePath()) & "components";
Yes, it's not really matches your problem, just an example.

Related

Graphs in Lucee

I see an error using CFCHART with Lucee. Same code works in CF. But in Lucee it try to refer to a file graph.cfm in a folder lucee.
mytestserver.com/lucee/graph.cfm?img=026f01d7b8c85b891a9c35c102623747&type=png
Do I need to create any mapping? Should this mapping be in Lucee admin or in IIS?
The short answer is: No, you don't need to add any additional mapping in IIS, nor in Lucee or Tomcat.
I've seen this question here for too long, so I'm placing an answer here to shed some light into Lucee's graph.cfm.
Some tags in CFML need to create additional image files to later embbed them as an inline HTML element into the reendered output altogether. Examples for such file creation are <cfimage type="captcha" ...> or like you have already noted in your issue, <cfchart>.
For such functionality Lucee needs to create these files temporarily somewhere and also make them publicly available. To achive this for cfimage/cfchart, Lucee creates the files in the web context folder of your webroot (which typically is located at path-to-your-webroot\WEB-INF\lucee\temp\graph ) and embbed them inline with a link to graph.cfm. The template graph.cfm just reads the temporary file from that folder, and delivers it in realtime to your application.
If you want to take a look into Lucees original graph.cfm, we can take a peek thanks to OpenSource:
source of Lucees graph.cfm at github
In order to make the files and the template graph.cfm temporarily publicly available, which by the way sits behind the WEB-INF folder ( which is also hidden/blocked by default in Tomcat for securtiy reasons), Lucee MUST have a virtual mapping. But you don't need to set it up, because these are already set up by default. You can see this in the image below taken from the "Mapping"-section of Lucee Administrator:
Because graph.cfm is a .cfm file, IIS will redirect the request directly through the implemented CFML connector ( probably Boncode Connector ) per AJP to Tomcat. Thus you don't need to set any mapping in IIS neither.
Because you have not submitted any additonal error information, such as http error codes or stack traces, I don't have any clue of what might be the cause of your error. It may also be some incompability issue which might be addressed if you submit it to the Lucee core team.
Another possibility is that many installation guides advise you to lock down the "/lucee/" path with IIS URL Rewrite Module, because this is also the path where the Lucee Administrator sits behind. If so, you can change the setting in IIS Rewrite Rule and adapt the rule in such a manner, that it would not block the graph.cfm.
It's also important to note that many of these cftags are implemented as Lucee extensions (.lex files). These are not necessarily pre-shipped or pre-installed in Lucee, but you may install it within Lucee Administrator or get them from Lucees Download site and upload it through your Lucee Administrator in the "Extension" section.
I've just encountered this too. Issue being though the the default mapping still don't navigate to "graph.cfm" so we've added an IIS virtual mapping instead.

Why is CreateObject with a dot-notation path to the component not working using CF Administrator Mappings that define the path to the CFC directory?

I am working on a web app already on the production server based on CF code that uses and depends on the CF Administrator Mappings to locate CFCs. I have a directory structure like this:
Webroot/
_TaskDir/
Application.cfm
myFile.cfm
CFC/
component1.cfc
...
app/
Application.cfm
index.cfm
...
My Mappings in CF Administrator has something like:
Logical Path: /myComponents
Directory Path: C:/Projects/Code/.../CFC/
Most of the app is under the app directory and uses calls to create objects all over the place like:
<cfset myCFCojb = CreateObject("component", "myComponents.component1").init()>
There are some scheduled task type scripts in another folder at the webroot (_TaskDir) that calls the CreateObject method in the same way as everywhere else, using the dot notation to specify the path to the components mapped directory. It supposedly has been working fine on production but for some unknown reason I am finding it doesn't work in this directory in my dev environment. The CreateObject works fine in the rest of my app, but when put into scripts in this folder it fails.
By fails, I mean i get a NullPointerException error. If I change the dot-notation path to a physical path (since both paths are within the webroot) such as CreateObject("component", "/CFC/component1").init() then it's fine. It's just the dot notation and mappings that seem to be ignored in just this directory.
Is this because this folder is outside the app directory which has the main Application.cfm and that _TaskDir has it's own Application.cfm? I would think the Mappings would work for either.
The first part of the stackTrace is:
java.lang.NullPointerException at
coldfusion.util.Utils.getDirectoryFromPath(Utils.java:350) at
coldfusion.runtime.TemplateProxyFactory.getTemplateFileHelper(TemplateProxyFactory.java:1638)
at
coldfusion.cfc.ComponentProxyFactory.getProxy(ComponentProxyFactory.java:51)
at coldfusion.runtime.CFPage.CreateObject(CFPage.java:6354) at
coldfusion.runtime.CFPage.CreateObject(CFPage.java:6373)...
I am using CF2016 in a Tomcat container.
I found the problem. Found out that the version of Tomcat (8.5.20) I am using as the container for my Apache server is now case sensitive. I ran 3 scripts from my _TaskDir directory specifying the URL with the wrong case (_Taskdir), first 2 ran fine. The 3rd was the one that was trying to run CreateObject using Administrator Mappings to find the CFC directory. The URL is apparently being used to comparie with the Mappings paths. With the wrong case being used in the URL is impacting the dot-notation path to the CFC directory. At least I know how to resolve this now.
If you can shed more light on how this case sensitive paths is impacting CF, I'd like to know more. If there is an article on this, please share.

Could not find the ColdFusion component or interface

I had a Mura 5 site, Admin stopped working with CF11 update.
I downloaded Mura 6, pasted site content in it, applied updateDB from url to the old database and it updated the DB.
Now admin area is working but i am getting the following error on client area.
Could not find the ColdFusion component or interface C:\sites\mura\test_site1\includes\servlet.cfc.
Ensure that the name is correct and that the component or interface exists.
The only problem is it is looking in old folder name mura instead of root folder of site which I named mura-6.
I don't know where can i change that to fix it. I didn't find any settings in tsetting nor in settings.ini.cfm(this has an abort tag on start btw)
I have also applied appreload, fuseboxreload and there is no mapping i found.
please guide.

ColdFusion cfselect binding not working on production server

I have a few related selects that work perfectly on a testing server with very loose security (basically just a simple default install of CF 10).
I have tried to implement the CF 10 lockdown guide on the production server and all seems well, except that related select don't work. That is, the first select in the chain doesn't populate and therefore, none of the related selects populate either.
I even recreated Ben Forta's art media example: perfect on the testing server, no triggering in production.
All other CFC functions seem to work: SELECT and INSERT queries are just fine. Only CFSELECTs with bindings are hosed. I pretty sure that the problem is a server configuration. The same pages worked just fine on our old CF 9 box. Any ideas would be helpful.
My advice to you would be to NOT use cfselect or any other UI stuff in ColdFsuion - It only causes more headaches than it gets rid of.
That being said, if you followed the lockdown guide, you should have limited access to the CFIDE directory - which is needed for any of the ColdFusion UI stuff. There is an option in CF Admin to use a 'custom' path for the scripts ColdFusion uses - it is on the main Settings page. Set this value and create a virtual directory in IIS with the same name pointing to the {cfroot}CFIDE/scripts directory.

Can't Open Web forms for marketers Form Designer or Security Manager

I have had WFFM running on a Sitecore instance for a while, but it has recently stopped working. When I go to "Form Designer" on an existing form, I get the standard Sitecore "The requested document was not found" page.
Requested URL: /applications/modules/web
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
Note that the requested URL is stated as /applications/modules/web instead of /applications/modules/web forms for marketers.
A lot of development has occurred on this site recently, so I'm not sure when exactly this started happening.
Additional: info:
Folder and file permissions are correct.
I've tried reinstalling the WFFM package, and made sure that all the files are in place.
Several processors have been added to the HttpBeginRequest pipeline, but I removed them all to test if they were the cause - they weren't.
I haven't upgraded Sitecore since WFFM was working and the version is correct.
No errors are logged
EDIT
This also seems to be affecting the Sitecore Security Editor:
Requested URL: /appl
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
EDIT 2
Further investigation with this is making me think it is related to the Requested URL. I originally thought the the "Not found" page was displaying the requested url incorrectly. However, if I attempt to goto mysite.com/sitecore/shell/applications/fake folder with spaces/fake page with spaces I get this error message:
Requested URL: /applications/fake folder with spaces/fake page with
spaces
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
As you can see the Requested Url is correct in the error message. So in relation to my problem, I think maybe Sitecore is requesting the wrong URL in the first place.
Additionally if I go to the go the following url by typing directly into the browser, then the Security Editor opens as expected:
mysite.com/sitecore/shell/Applications/Security/User-Editor
This is quite old now but I thought I'd provide an update for anyone else who encounters the problem.
Unfortunately, Sitecore support weren't able to help beyond pointing out that setting the addAspxExtension attribute to 'true' in the link provider seemed to solve the problem. This may have been acceptable except that extensionless URLs were important to the customer.
In the end I had to amend my link provider so that addAspxExtension is set to 'true' in the web config, and then I set it to false inside the GetItemUrl method for specified sites only.
So now whenever the context site is 'Shell' or 'Admin' etc, the extensions are added by default, but switched off in my main website.
Of course, this is a work around. I still don't know how to actually fix the problem
So the first thing that I am going to tell you is that I suspect that there is something wrong with your site declaration for Sitecore Modules. In your web.config, there's a site declaration for "modules_shell" and "modules_website". Those are where the code files that run the modules are usually located... a shell folder to run the parts that run in the Sitecore shell and a web folder to run the part that is accessed by the externally facing site. Please check your site declarations (and the form.config file) to make sure that you're not in live mode or something like that. I would definitely say that this is where you should start looking.
The next thing is to say that your comments about Sitecore not serving a url in the /sitecore/shell directory is really not surprising. Sitecore processes all requests unless you specifically tell it to ignore requests (like setting it in the IgnoreUrlPrefixes in web.config), it's going to try processing it. Like going to /sitecore/shell/applications gives me a layout error because it doesn't have anything set to handle that request. Now your error suggests that there is something wrong with Site declarations.. however, even if they were all right, it still wouldn't work.