Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ghost install in sub directory support #527

Closed
3 tasks
ErisDS opened this issue Aug 25, 2013 · 38 comments
Closed
3 tasks

Ghost install in sub directory support #527

ErisDS opened this issue Aug 25, 2013 · 38 comments
Assignees
Milestone

Comments

@ErisDS
Copy link
Member

ErisDS commented Aug 25, 2013

We want to support sub directories so that someone can feasibly install their Ghost at myurl.com/blog/.

  • Parse the subdirectory out of the config.url
  • Fix up Ghost to then honor that sub directory where necessary. This includes in the {{url}} theme helper (Theme API: {{url}} handlebars helper #528), and probably most of the internal paths.
  • It would be awesome to do a temporary public demo install of this feature so it can be thoroughly tested.
@fform
Copy link

fform commented Oct 14, 2013

This is the very first thing I tried to do. I have a portfolio, and the blog is just a subpath /more

I want Ghost to live their so all of my content falls under one domain and I already have a website that I don't want to hack into a bunch of posts inside of Ghost.

@gotdibbs
Copy link
Contributor

@fform In the meantime you could consider putting your blog on a subdomain a la blog.example.com instead of example.com/blog/. That's what I've done with my website.

@jgillich
Copy link
Contributor

Is this issue really about config.production.url? Or is it just outdated?

I'm running Ghost behind a reverse proxy so this is absolutely necessary...

@ErisDS
Copy link
Member Author

ErisDS commented Oct 14, 2013

It's out of date - we were trying to keep URLs out of Ghost for as long as possible to prevent the WP problem where they creep into places they're not needed. I've updated the issue.

@RemoteCTO
Copy link

+1 for this feature. Didn't realise it didn't support it until I got into a pickle with it. Starting on a subdomain for now, but want to migrate asap.

@RyannosaurusRex
Copy link

+1 for this as well. My predicament is my wordpress permalinks are %category%/%postname%, but basically everything as in the "blog" category. While plugin support would let me do some 301s and be just fine, this feature would let me just install Ghost at /blog, pop a landing page up at /, and be set.

@ErisDS
Copy link
Member Author

ErisDS commented Oct 20, 2013

We really want to roll this feature in 0.4, just needs someone to pick it up ;)

@halfdan
Copy link
Contributor

halfdan commented Oct 21, 2013

Dibs - I'll work on it.

@RemoteCTO
Copy link

Nice one, thanks @halfdan. I'd love to get involved but been stacked-out lately.

@ghost ghost assigned halfdan Oct 22, 2013
@ErisDS
Copy link
Member Author

ErisDS commented Oct 29, 2013

@tgriesser - this seems much more of a contribution towards #1326 ?

This snippet doesn't cover how to make Ghost itself respect subdirectories, which is what this issue is about and should be relatively straight forward with express mounting.

I really want to get #1326 and other refactoring things done - but they never seem to get past first base.

@risacher
Copy link

I think I have this working.

Temporary live demo site at https://risacher.org/ghost-blog/
credentials: junk@risacher.org/password

Unfortunately it's a moderately invasive change since it involves every URI generated by Ghost or Casper, and even required a change to connect-slashes

@RemoteCTO
Copy link

Hi Daniel, thanks for putting that up. Just tried it and got this however:

screen_shot_2013-10-31_at_09 22 56-3

@risacher
Copy link

Heh, subtle irony here... Shortly after getting it working, I started rebaselining on the current HEAD, since my fork was about 3 days behind. In doing so, I broke the working install when I moved it out of the way.

The ironic bit: since the feature I'm working on allows multiple simultaneous instances, there was no reason to move it out of the way.

risacher added a commit to risacher/Ghost that referenced this issue Oct 31, 2013
…everse proxy

addresses TryGhost#527
- useful when running behind a reverse proxy
- for consideration/discussion only.  I actually don't advocate this
- instead of having a base_url string to prepend to URIs, a more flexible approach would be a local_url() mapping function
- since it is targeted at node-http-proxy, it fixes generated URIs but does not change the routes listened for.
- there is a corresponding pull request for Casper
- there is a corresponding pull request for connect-slashes

fix {{url}} helper
@risacher
Copy link

This work is not done, but anyone who wants to see what I've got so far can look at:

https://github.com/risacher/Ghost/compare/base_path
https://github.com/risacher/Casper/compare/base_path

The basics seem to work, but image uploading (and sometimes downloading) are still broken.

On reflection, I don't like my own approach that much. A function to transform the URIs would be much more general than adding in a string. I'm thinking about starting over with that approach.

@halfdan
Copy link
Contributor

halfdan commented Nov 1, 2013

@risacher Interesting approach, but not what it should look like. I'm working on a PR, so you might just wait for that.

@rotatingJazz
Copy link

+1 on the feature, extremely important for seo reasons (to have your blog content on the main domain)

@halfdan
Copy link
Contributor

halfdan commented Nov 14, 2013

Got three questions regarding the implementation (@ErisDS):

  • Q1: I'm parsing the url to get the path from the config. I added the path to blogGlobals. Should blogGlobals().url then have the path removed?
  • Q2: For res.locals.path I created another res.locals.rootPath (basically path without the subdir - so Ghost root) - this is needed for the helpers in core/server/helpers/ since they apply regexes on this.path. Does that seem reasonable?
  • Q3: What is the best approach to test the subdir functionality? My idea would be to have a third travis config that is configured with a subdirectory. Any better ideas?

@ErisDS
Copy link
Member Author

ErisDS commented Nov 14, 2013

Q1: I don't think so, in themes we'll want the path for making relative URLs and the url+path for making absolutes, but rarely if ever need the stripped URL? That's my logic anyway
Q2: Sounds good
Q3: 3rd Travis config seems like a lot of Travis configs esp when you consider adding node v0.12 Can we isolate the unit tests which are relevant, and create an express server instance with a slightly different config and run it as an extra test suite so test-paths? Not sure if that's possible because writing to config isn't really a thing.. just throwing it out there.

@hswolff might be worth you glancing over this stuff & adding your own 2c because it's quite relevant to what you are working on

@hswolff
Copy link
Contributor

hswolff commented Nov 15, 2013

Q1: I'm not clear what you mean here.

If the url from the config files is http://ghost.org/blog/ then what is going into blogGlobals().url?

Q2: Just a nit, maybe call res.locals.rootPath res.locals.ghostRoot as that may be clearer? Up to you, just a nit-pick. 🍡

@halfdan
Copy link
Contributor

halfdan commented Nov 15, 2013

@hswolff:

Q1: Nevermind :) I think @ErisDS is right and it should just be the value from config.
Q2: Sounds good - had this in mind already.

@halfdan
Copy link
Contributor

halfdan commented Nov 17, 2013

@ErisDS: Do you see an easy way of prepending the subdir to everything before https://github.com/TryGhost/Ghost/blob/master/core/server.js#L226? Basically all the shared/ and built/ stuff.

@ErisDS
Copy link
Member Author

ErisDS commented Nov 19, 2013

@halfdan No, but I think the work @hswolff is doing in #1390 should mean that we only have to hard code them for a short while.

@mjbshaw
Copy link
Contributor

mjbshaw commented Nov 26, 2013

I wasn't sure if I should make a separate issue, but I figure it might be relavant enough not to. After commit e210e75, I tried putting ghost in a subdirectory ("+"), and got this exception (doing a clean initial setup of Ghost):

$ npm start

> ghost@0.3.3 start /Users/mjbshaw/Projects/Website/+
> node index

connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0
connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0
connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0
Ghost is running in development... 
Listening on 127.0.0.1:2368 
Url configured as: http://127.0.0.1:2368/+ 
Ctrl+C to shut down
GET /+/ghost 301 6ms
GET /+/ghost/ 302 22ms - 88b

ERROR: Failed to lookup view "signup"
ErrorPage
Ghost caught a processing error in the middleware layer.

Error: Failed to lookup view "signup"
    at Function.app.render (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/application.js:493:17)
    at ServerResponse.res.render (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/response.js:801:7)
    at adminControllers.signup (/Users/mjbshaw/Projects/Website/+/core/server/controllers/admin.js:116:13)
    at callbacks (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/router/index.js:164:37)
    at middleware.redirectToDashboard (/Users/mjbshaw/Projects/Website/+/core/server/middleware/middleware.js:70:9)
    at callbacks (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/router/index.js:164:37)
    at param (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/router/index.js:138:11)
    at pass (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/router/index.js:145:5)
    at Router._dispatch (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/router/index.js:173:5)
    at Object.router (/Users/mjbshaw/Projects/Website/+/node_modules/express/lib/router/index.js:33:10) 

GET /+/ghost/signup/ 500 21ms - 2.85kb
GET /ghost/css/screen.css/ 404 34ms - 1.5kb
GET /ghost/img/404-ghost@2x.png/ 404 34ms - 1.5kb

Going to http://127.0.0.1:2368/+/ghost redirected to http://127.0.0.1:2368/+/ghost/signup/ which crashed, saying it couldn't lookup view "signup". If I don't put Ghost in a subdirectory, it redirects fine to ghost/signup. My config.js is the same as the example.config.js, except with the development URL being set to url: 'http://127.0.0.1:2368/+'.

It looks like there's still a bit more work to do with this. If I'm reporting this prematurely and it is known that commit e210e75 alone isn't enough (or if setting the url to contain the subdirectory in config.js is not the right way to test this feature), then just ignore this.

@halfdan
Copy link
Contributor

halfdan commented Nov 26, 2013

@mjbshaw The feature isn't finished yet (that's why the issue is still open). Right now only the front end will work - the admin area should show a blank page and not fail as it does in your case.

I'll look into this issue as I finish the implementation of this functionality.

halfdan added a commit to halfdan/Ghost that referenced this issue Nov 27, 2013
halfdan pushed a commit to halfdan/Ghost that referenced this issue Nov 27, 2013
@ThisIsMissEm
Copy link

@halfdan any further progress on this / what's remaining? I can help out tomorrow afternoon to get this done.

@halfdan
Copy link
Contributor

halfdan commented Nov 29, 2013

@miksago It's gonna be finished by then :) Thanks!

@ThisIsMissEm
Copy link

@halfdan awesome! Looking forward to testing this out!

@ErisDS
Copy link
Member Author

ErisDS commented Dec 4, 2013

@halfdan, what is left to do on this now?

I did notice that the link to the password reset on the sign in screen does not respect the subdir.

@halfdan
Copy link
Contributor

halfdan commented Dec 4, 2013

Oh, it's all done - I just haven't pushed the changes yet. Meant to wait for Travis build to pass before pushing.

@ErisDS
Copy link
Member Author

ErisDS commented Dec 5, 2013

It's not perfect, but currently working much better than it was.

@jbrooksuk
Copy link

I want to do a similar thing, except have the posts read at /blog so you access the homepage at http://example.com but then the permalink is http://example.com/blog/hello-world.

@jgillich
Copy link
Contributor

@jbrooksuk That's already in the code as well, the only thing missing is a proper UI to configure it (see #1631).

@ErisDS
Copy link
Member Author

ErisDS commented Dec 17, 2013

Hey @halfdan I know you're totally snowed under and it's nearly the holidays, so could you please update me on where you are at, and push up your latest work? I'd like to help please!

@ErisDS
Copy link
Member Author

ErisDS commented Dec 18, 2013

@halfdan ping ;)

@halfdan
Copy link
Contributor

halfdan commented Dec 21, 2013

Soooo.. PR is in - I decided not to add a utils module since @hswolff refactored most of the paths nicely into config/paths.js. The new webroot attribute makes it dead easy to add the subdir to any path where needed. My module would've included a function that automatically prepends the subdir:

utils.resolveSubdir('/ghost/foo/bar'); // -> /subdir/ghost/foo/bar

vs.

config.paths().webroot + '/ghost/foo.bar'; // -> /subdir/ghost/foo/bar

I think the slightly shorter module version isn't enough to introduce a new module to ghost.

halfdan added a commit to halfdan/Ghost that referenced this issue Dec 21, 2013
fixes TryGhost#527
- Fix image upload in backend
- Use config.paths().webroot where necessary
@ErisDS ErisDS closed this as completed in c81c43a Dec 21, 2013
@esoubihe
Copy link

Is this implemented in 0.4?

@ErisDS
Copy link
Member Author

ErisDS commented Jan 13, 2014

@matthojo
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.