Keystone-classic: Running KeystoneJS in a subdirectory

[AMRoche]

Hi guys! Trying to run KeystoneJS in a subdirectory, and had to do a lot of messing around just to make everything work properly on the front-end, but have now run in to the problem that elements in the admin panel CSS aren't loading ... any thoughts?

Basically, the site is running under the /news/ directory, with all requests to the server being proxied there. However, the keystone instance is trying to access its' own assets in the stylesheets at /keystone/ instead if /news/keystone/. I was able to get stylesheets by adding another proxy rule in to apache to get the CSS, but not entirely sure how to tackle this one!

Any help greatly appreciated!

[Awk34]

I've also had trouble with running keystone in a subdirectory. I followed the adding keystone as a sub-app guide, but trying to go to mysite.com/content/keystone just directs me back to mysite.com. I'm using the angular-fullstack generator. Here's what my directory structure looks like:

aksite

• server.js
• gruntfile.js
• ...
• /app
• /content
  
  
  
  • keystone.js
  
  
  • ...
  
  

Is your structure any similar?

[AMRoche]

Nope, sadly not!

The way the site works is it's got keystone generating the site by itself and in node, but tacked on to the rest of an enterprise level site which is _not_ node based at all.

As a result, the subdirectory is redirected to the folder with keystone in it, which keystone things is the root context, where it isn't.

What I ended up doing was adding a "subdomain" clause to the keystone.js file and propagating it through to my views, with a redirect to the admin panel such that it was running from the root directory of a dummy site.

[Pinpickle]

Did you use keystone.mount? I found that worked after quite a lot of
messing around, but for the most part everything made requests to the right
place (except some redirects were a bit off). I think the use of proxies is
the source of your problem.

On Thursday, June 26, 2014, Alex Roche [email protected] wrote:

Hi guys! Trying to run KeystoneJS in a subdirectory, and had to do a lot
of messing around just to make everything work properly on the front-end,
but have now run in to the problem that elements in the admin panel CSS
aren't loading ... any thoughts?

Basically, the site is running under the /news/ directory, with all
requests to the server being proxied there. However, the keystone instance
is trying to access its' own assets in the stylesheets at /keystone/
instead if /news/keystone/. I was able to get stylesheets by adding another
proxy rule in to apache to get the CSS, but not entirely sure how to tackle
this one!

Any help greatly appreciated!

—
Reply to this email directly or view it on GitHub
https://github.com/JedWatson/keystone/issues/442.

[Awk34]

I am. Here is my server.js file: http://pastebin.com/kTueV451

[JedWatson]

The issue with the fixed paths to the public assets was a known one when mount was split out into its own method. Because they're currently hard-coded through the js and css files (which is a fix for other issues) I'm not sure on a simple way to address it within Keystone itself.

On a completely different note, we've been thinking about how to theme the Admin UI - which would require explicitly writing to the less files then generating the css files from that, which could happen on keystone.start(). Kind of tricky to do anything else (e.g. build scripts) because of the way keystone is bundled as a node_modules package.

Maybe, if we pushed that through, we could also finally implement proper dynamic pathing for static assets at the same time.

@AMRoche if you could pull the ./public/ assets out and host them (separately) in a /keystone mapping on your server, potentially separate from the node.js app, it might work around the problem in the meantime?

[jtymann]

All,

So I have run into an interesting scenario regarding this which has caused me to look into it more. I am currently writing a framework that operates via a series of plugins/modules (node modules that follow a specific interface). Long story short this framework exposes a webserver on a given port and routes requests to the given plugins accordingly. Ex: Plugin foo runs an express server (that doesn't listen on a port) and then a request comes in to http://my.cool.server/foo the request is routed to the foo plugin's express server to handle the response.

So basically the first level sub directory in this environment is a namespace for the plugin.

The reason I bring this up is for one of the plugins I would like to use Keystone.js, and thus we have the issue of sub folders again (and I don't want to use another namespace specifically for keystone).

I can get the app to serve out under the sub folder fine, but like everyone else I am having issues with the css and js.

I was looking at the keystone.js source code and I noticed that all the includes are written like:

script(src="/keystone/js/common/ui-location.js")
or
a(href='/keystone/signout')

What I find interesting about this is, it is actually a simple fix (just you need to do it EVERYWHERE)

rather than using an absolute path, you just need to reference everything relatively.

So script(src="/keystone/js/common/ui-location.js") turns into script(src="keystone/js/common/ui-location.js")

From my initial looks, this would be highly effective and not break anything. Currently I am working on making the change in my version, and may submit it as a pull request if all goes well. But I wanted to ask if anyone knows the reason or why everything is included via absolute paths rather than relative paths?

[jtymann]

All,

As a followup I have forked the keystone repo, and currently have a version that supports sub directories.

The fork can be found here: https://github.com/jtymann/keystone

The usage is fairly simple. When calling keystone.init there are two new options to pass "webroot" and "cmsdir". The webroot option allows you to change the base path of keystone. So if you would like to host keystone from "http://www.mysite.com/blog/" you would pass in "webroot" : "/blog/". The cmsdir directory allows you to change the name of where the keystone backend is hosted. By default this is keystone. So in the above example by default the admin panel is located at "http://www.mysite.com/blog/keystone", using the cmsdir option you can change this. For example if you wanted the admin site to be hosted under the name "admin" you can pass the option "cmsdir" : "admin".

Below is an example init call:

keystone.init({

'name': 'Keystone',
'brand': 'Keystone Co.',

'less': 'public',
'static': 'public',
'favicon': 'public/favicon.ico',
'views': 'templates/views',
'view engine': 'jade',

'emails': 'templates/emails',

'auto update': true,
'session': true,
'auth': true,
'user model': 'User',
'cookie secret': 'lasdjhfalsdkjfhalsdjkfhasldkjfhasldjfahsdlfasjkdhf',

'webroot': '/blog/',
'cmsdir': 'admin',

});

[ignlg]

As a side note, the option names don't seem self-explained. I'd suggest something more 'literal' like:
web root
admin route

[frederik]

That'd actually solve my problem as well - I've been looking into other ways to host keystone in a sub directory - seems like there is none.

@jtymann any new ideas on this one since October?

[jtymann]

Unfortunately I was researching this for a project, and ultimately decided to move a different direction. The fork at https://github.com/jtymann/keystone should be usable.

[frederik]

I ended up hijacking the res.send and res.redirect methods - its nasty because I string replace but then this replacement is only active for my keystone routes so my normal app - works out fine for now (without me having to fork).

Adding a prefix variable to the templates/less would be really great though. Default could be /keystone so nothing changes.

I added my workaround to https://github.com/frederik/keystone-admin-routes (just a temporary solution since I needed to get this going with subdirectories). Feedback and pull requests are welcome.

[mxstbr]

I'll close this due to inactivity, let me know by commenting if you still want this!

[licx]

Adding a webroot setting to keystone.init would be super useful

[Terrafire123]

Yes! I'm trying to do a reverse proxy, and because Keystone.js doesn't support something like webroot="", this has become a lot harder than it should be.

[peter-mouland]

~I know plus 1 is super annoying, but due to the gap in comments, it's probably worth while adding why a webroot would help us out.~

~locally, we don't need it, but on our CI env, they add /app-name to the urls which means using /keystone doesn't work. So we'd be interested in using webroot for this reason~

scratch that - due to the fact we are trying to us this headless, this admin path pr solved it for us:
https://github.com/keystonejs/keystone/pull/1820