[closed] FarCry 7.2.8: webtop application.cfc redirects to install directory for non-webroot install

proc · December 29, 2016, 10:02am

Hey there,

I tried to install FC 7.2.8 in a subdirectory of the webroot (like discussed here) but when trying to access the webtop, the webtop/application.cfc function getProjectConstructorLocation() always redirects to the install directory.

I need to install multiple FarCry instances on one server (currently a Mac w/ 10.12, Apache, CF 11, and MySQL 5.x), and they need to work with different cores as well. So, what I want is basically:

/sites/appA – /appA [1]
/sites/appA/core
/sites/appA/core/webtop – /webtop-appA [2]
/sites/appA/plugins
/sites/appA/projects/fcappA
/sites/appA/projects/fcAppA/www – /fcAppA [3]

/sites/appB – /appB [4]
/sites/appB/core
/sites/appB/core/webtop – /webtop-appB
/sites/appB/plugins
/sites/appB/projects/fcappB
/sites/appB/projects/fcAppB/www – /fcAppB

[1] This is the usual “/farcry” mapping. I changed it because the two sites need to have different mappings on one server. In order to make it work, I replaced all occurrences of “/farcry/core,” “/farcry/plugins,” “farcry.core,” and “farcry.plugins” with “/appA/core,” etc. (Dreamweaver is a great tool for this ) I did this with an old 4.X installation – works.

[2] The mapping to the site’s Webtop application. These two need to be different in order to coexist on one server.

[3] The mapping to the site root for “appA.”

[4] The “farcry” mapping for the second installation, as mentioned by Justin Carter in the above linked thread.

Since the non-webroot install as described in the already mentioned post did not work, I installed in the webroot (/sites) and copied/moved the underlying files and directories according to the above displayed structure. I moved everything outside the original “/farcry” directory to the “/fcAppA” folder.

Now, when I try to call the webtop application with the URl http://127.0.0.1/webtop-AppA, I get redirected to the installer because of the function getProjectConstructorLocation() in webtop/application.cfc:

	<cfset var loc = "" />
	<cfset var virtualDirectory = "" />
	
	<!--- strip the context path first (for J2EE deployments) --->
	<cfset var script_path = right( cgi.SCRIPT_NAME, len( cgi.SCRIPT_NAME ) - len( cgi.context_path ) )>

	<!--- Get the first directory after the url if there is one (ie. if its just index.cfm then we know we are just under the webroot) --->
	<cfif listLen(script_path, "/") GT 1>
		<cfset virtualDirectory = listFirst(script_path, "/") />
			
		<!--- If the first directory name is the same name as the plugin, then we assume we are running the project from the webroot --->
		<cfif virtualDirectory EQ arguments.plugin>
			<cfset virtualDirectory = "" />
		</cfif>					
	</cfif>

	<!--- If we ended up with a virtual directory we check to see if there is a farcryConstructor --->
	<cfif len(virtualDirectory) AND fileExists(expandPath("/#virtualDirectory#/farcryConstructor.#arguments.fileExtension#"))>
		<cfset loc = trim("/#virtualDirectory#/farcryConstructor.#arguments.fileExtension#") />

	<cfelseif fileExists(expandPath("/farcryConstructor.#arguments.fileExtension#"))>
		<!--- Otherwise we check in the webroot --->
		<cfset loc = trim("/farcryConstructor.#arguments.fileExtension#") />
	<cfelse>
		<!--- If all else fails... --->
		<!--- 1. See if the user has a cookie telling us what project to look at. --->
		<cfif structKeyExists(url, "farcryProject") AND len(url.farcryProject)>

The reason is that the variable virtualDirectory holds the value of the webtop mapping, in our example “webtop-AppA”. Now, there is no farcryConstructor.cfm script in that directory. Thus, the script tries the webroot directory, but since I need to run multiple FarCry installations, the web root directory doesn’t contain a farcryConstructor.cfm script either.

And since the webtop application doesn’t know anything about the “front-end” site either, there are no cookies or any information which joins those two.

So, long story short: How will this be done? Which step did I miss?

Any pointers are greatly appreciated.

Thanks,
Thomas

jeff · January 2, 2017, 9:36pm

Thomas,

My head hurts reading this :). Just so I’m clear, you want to run multiple sites all under the same webroot/domain, but use different versions of core for each one?

As an aside, it’s advised not to modify anything in core otherwise future updates could potentially be a bit of a problem.

If you really need to run all the sites under one web domain, a supported option is sharing the same FarCry core under said domain and is not difficult to setup (and does not require any modification of core). If that is acceptable, then we can help walk you through that.

Note: If the whole purpose for running all of these under one domain is just for your development needs (ie. running everything under the loopback address 127.0.0.1 like in your example), then I suggest tossing that method out the door. There are far better ways to setup your development environment, and if you’d like we can help walk you through setting that up. This wouldn’t just make things easier for FarCry installations, but for any other web application, framework, etc that you need going forward. Plus you’ll be able to better replicate your clients’ production environments (which is extrememly helpful for future maintenance and debugging).

Jeff

proc · January 3, 2017, 3:20pm

Jeff,

Thanks for responding and apologies for making your head hurt.

Yes – on the development stage, I need to run all sites on one box (127.0.0.1) but with different FarCry cores (and databases).

On the production system (which is a shared environment), there is one main domain pointer and several “sub-pointers” (<webroot>/siteA will be accessed via www.siteA.com, <webroot>/siteB will be accessed via www.siteB.com, etc.). There may be different FarCry core versions for the different sites, so sharing one farcry core is not an option. (One of the sites is still running FarCry 4.X. )

Also, there are other sites running in the same shared environment. So, using the /farcry mapping will not be possible; and the same applies to the /webtop mapping (no matter whether on IIS or Apache), doesn’t it?

The only way I found to make things running is to modify the FarCry core files as described. (And yes, I’m well aware of the fact that any new core version will require to invest some hours.)

That said, anything you might be able to share will be greatly appreciated. (So far, the only way to make things work was to alter the FarCry core as described. It worked with FarCry 4.X, and it still does with 7.2.8. Not a little achievement, I’d say.)

I guess it would be great if together we would be able to describe the different options. Then, in the future, people would only have to look-up the documentation.

– Thomas

blair · January 3, 2017, 8:25pm

Thomas,

You should really look at runing your local sites on separate domains using
your hosts file. Not only is modifying core not recommended, but you’re
currently in a position of running different code locally than you are in
production, which is a problem for testing.

Blair

proc · January 4, 2017, 8:41am

Blair,

Thank you for joining the discussion. I will definitely give your suggestion a look.

However, the local set-up will be the same as the production set-up . (Hence my original questions.) The sites are fairly small and will perfectly coexist on the production system (a shared hosting environment), too.

– Thomas

blair · January 4, 2017, 12:00pm

Yes, I’m talking about having the sites on one box, but with different
domains.

Blair

proc · January 4, 2017, 12:55pm

Then, I guess, I would need some pointers.

– Thomas

justincarter · January 11, 2017, 1:34am

In production, do all your sites run on different host names?

www.siteA.com
www.siteB.com
www.siteC.com

If that is the case then they are effectively 3 separate websites each with their own webroot, so they should have their own site/virtualhost settings in IIS/Apache and can have their own virtual directories for your /farcry and /webtop mappings, and there should be no mappings in the ColdFusion Administrator.

If that’s not the case, perhaps you can clarify exactly your directory structure, your webserver configuration (each of your domains, each of your web roots, each of your configured aliases/virtual directories), etc.

For example, this would be the directory structure of 3 separate sites each with their own core;

websites
├── siteA (/farcry virtual directory in siteA)
│   ├── core
│   │   └── webtop (/webtop virtual directory in siteA)
│   ├── plugins
│   └── projects
│       └── siteA
│           └── www (webroot of siteA)
├── siteB (/farcry virtual directory in siteB)
│   ├── core
│   │   └── webtop (/webtop virtual directory in siteB)
│   ├── plugins
│   └── projects
│       └── siteB
│           └── www (webroot of siteB)
├── siteC (/farcry virtual directory in siteC)
│   ├── core
│   │   └── webtop (/webtop virtual directory in siteC)
│   ├── plugins
│   └── projects
│       └── siteC
│           └── www (webroot of siteC)
└── ...

This would be the directory structure of 3 separate sites with a shared core and plugins (generally not recommended as there is little to no benefit over the above method);

websites
├── farcry (/farcry virtual directory in siteA and siteB and siteC)
│   ├── core
│   │   └── webtop (/webtop virtual directory in siteA and siteB and siteC)
│   ├── plugins
│   └── projects
│       ├── siteA
│       │   └── www (webroot of siteA)
│       ├── siteB
│       │   └── www (webroot of siteB)
│       └── siteC
│           └── www (webroot of siteC)
└── ...

You’ll need to do this with a clean copy of core that has no modifications otherwise it’ll be difficult for you to continue to upgrade core each time we do a maintenance release or new minor or major release. In addition, it’s likely that sub-directory installation support will be removed in FarCry 8. x as we’re planning optimisations that are specifically geared towards running one single application at a time (we haven’t used sub-directory installations for any clients in the past 7+ years )

proc · September 26, 2017, 3:56am

The original issue is popping up again, now with FarCry 7.2.9 in a production environment. It is probably my understanding…

The FarCry installation only serves one site, and the directory structure is as follows (so: only one site with one farcry core installation):

webroot
└── farcry
    ├── core
    │   └── webtop (/webtop virtual directory )
    ├── plugins
    └── projects
        └── siteA
            └── www (/siteA virtual directory)

When firing the request for the webtop, the core Application.cfc file wants to redirect to the install directory.

To me, it seems that the reason for this is the getProjectConstructorLocation() function:

The function looks up the virtual directory of the webtop.
If no FarCry constructor can be found there, it checks the webroot directory.
It checks for any cookies which might contain information.
As a last resort, it tries to retrieve information from the server scope (which is accessed in the Application.cfc OnRequestStart() method).

While the thing works on multiple development stages (both with ColdFusion 2016 and ColdFusion 11 on macOS Sierra), it fails on the production system (running own IIS 8.5).

My questions are:

Why is getProjectConstructorLocation() called when initializing the Application.cfc, i.e., before calling the OnRequestStart() which fills the server.stFarcryProjects structure?
What to do if one has no access to the server scope (for example, in a shared hosting environment)?
There really is no reference to the /siteA virtual directory at all before falling back to calling the install routines on the way through Application.cfc.

Obviously, I’m missing something here. Any thoughts anybody?

blair · September 26, 2017, 4:17am

What are you trying to achieve by mapping farcry/projects/siteA/www to
siteA? The typical setup is to map that directory to the webroot.
Another thing that can cause this issue is if the db isn’t set up correctly
and FarCry finds an empty database.

proc · September 26, 2017, 4:28am

In a shared environment, you may only have one /farcry mapping. If this is taken, you would have to alter the core (which, as I learned, is not recommended). The way things are set up now, you don’t need a /farcry mapping at all (because /farcry its located directly under the physical webroot).

The database is not empty. I copied it from the development stage to the production system and verified that the transfer went ok.

justincarter · September 26, 2017, 4:52am

The configuration depends on your physical directory structure.

proc:

webroot
└── farcry
    ├── core
    │   └── webtop (/webtop virtual directory )
    ├── plugins
    └── projects
        └── siteA
            └── www (/siteA virtual directory)

If the web server is pointing to the webroot folder and you are trying to do what we call a “webroot” install that requires no /farcry alias/virtual directory/mapping, then you need to move the contents of projects/siteA/www into the webroot folder. That would leave you with this configuration:

webroot (webroot of siteA, inside here is index.cfm, farcryConstructor.cfm, etc...)
└── farcry
    ├── core
    │   └── webtop (/webtop virtual directory )
    ├── plugins
    └── projects
        └── siteA
            └── www (*contents moved into /webroot*, then www can be deleted)

Alternatively, if you want to keep the webroot inside projects/siteA/www then you need to follow the structure I posted previously;

websites
└── siteA (/farcry virtual directory in siteA)
    ├── core
    │   └── webtop (/webtop virtual directory in siteA)
    ├── plugins
    └── projects
        └── siteA
            └── www (webroot of siteA)

proc · September 28, 2017, 3:24pm

I’m sorry for the delayed response.

I understand what you are saying, and it seems that moving al lthe stuff to the webroot will be the only possibility to circumvent this.

However, what puzzles me is that my set-up workde on two different development systems (both Mac OSX though) but not in an IIS environment.

I still need to try it on the production system, though.

Also: If everything else fails, the getProjectConstructorLocation() function calls the webtop install script. Is this a good idea for a production environment, when every how-to tells you to disable/remove any installation scripts on production systems (just asking)?

I guess it would be a good idea to mention in the install scripts/README/documentation that the two options Justin mentioned are the only ones allowed for a successful set-up. This could help others who are new to FarCry to save time.

Anyway, I like the clean and sleek webtop UI. Great job!