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

Test deploying to Windows Azure #830

Closed
ErisDS opened this Issue Sep 18, 2013 · 43 comments

Comments

Projects
None yet
7 participants
@ErisDS
Member

ErisDS commented Sep 18, 2013

We don't imagine it's going to work, but it would be good to know what the blockers are and whether they can be mitigated in some way.

@ghost ghost assigned gotdibbs Sep 18, 2013

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Sep 19, 2013

Member

Summary

I tried this tonight against the a 30 day azure trial account. The frontend of the blog seems to run ok out of the box. It's the admin side of things that is borked. Deploy itself goes fairly smoothly.

Specific Issues Encountered

  1. Azure uses iisnode to spin up nodejs and manage its lifecycle. IISNode wants you to name your "entry point" server.js and not index.js. This can be resolved by overriding the web.config (eww), or just creating a server.js file that simply requires index.
  2. Azure seems to allow file access ok, but I think I'm "paying" for that at the moment. In other words, if you had just a free account, you wouldn't have file access and things like SQLite and uploading images would break altogether.
  3. THE BIG ONE. This issue prevented me from really testing too much further. Whenever I try to access anything on the admin side of things (signup, signin, et all), I get this error: "Error: the partial navbar could not be found". The first time I ran it, it couldn't find the notifications partial. I investigated this for quite a while and it seems like node is able to find the partials in the right folder and load them, but something chokes around registering them with handlebars as the handlebars.partials dictionary remains empty. I cannot reproduce on my machine, but I think @cgiffard said he could as well ... so this issue may not be azure specific.

Specifically What Works

These are the things that I noted as working after I removed the partials referenced in default.hbs in the admin views.

  1. The blog and it's default theme. Caveat: I haven't looked, but I don't think casper uses partials, so that may not work as well for themes.
  2. Content viewing and editing, including image uploads.
  3. User settings.
  4. Blog settings.

So as you can see really about 95% of it works, its just those darn partials. Might be worth trying to find someone at Microsoft who can help us take a look, or possibly seeing if @cgiffard has some time to step through the express-hbs module on his machine.

Summary of Setup Steps

These are the steps I took to deploy to Azure from my Windows 8 box. Pretty close to the standard deployment notes here.

  1. Get latest from GitHub.
  2. Run grunt build.
  3. Take the build output and place in another folder.
  4. Go to that folder, create a file called server.js.
  5. In the server.js file, all you need is one line: var GhostServer = require('./index');.
  6. Open core\server.js and find the line for server.listen. Swap ghost.config().server.port for process.env.PORT || ghost.config().server.port.
  7. Register for Windows Azure.
  8. Add a new website using Quick Create, select Local Git Respository as the deployment method.
  9. Navigate to the build output copied in step 3.
  10. Open a command prompt in the current folder.
  11. Run git init.
  12. Run git add --all && git commit -m "Initial Deployment".
  13. Run git remote add azure [URL OF DEPLOYMENT]. Note the git url in the screenshot below.
    git-instructions
  14. Run git push azure master.
  15. Access the website.
  16. Profit. 💸
Member

gotdibbs commented Sep 19, 2013

Summary

I tried this tonight against the a 30 day azure trial account. The frontend of the blog seems to run ok out of the box. It's the admin side of things that is borked. Deploy itself goes fairly smoothly.

Specific Issues Encountered

  1. Azure uses iisnode to spin up nodejs and manage its lifecycle. IISNode wants you to name your "entry point" server.js and not index.js. This can be resolved by overriding the web.config (eww), or just creating a server.js file that simply requires index.
  2. Azure seems to allow file access ok, but I think I'm "paying" for that at the moment. In other words, if you had just a free account, you wouldn't have file access and things like SQLite and uploading images would break altogether.
  3. THE BIG ONE. This issue prevented me from really testing too much further. Whenever I try to access anything on the admin side of things (signup, signin, et all), I get this error: "Error: the partial navbar could not be found". The first time I ran it, it couldn't find the notifications partial. I investigated this for quite a while and it seems like node is able to find the partials in the right folder and load them, but something chokes around registering them with handlebars as the handlebars.partials dictionary remains empty. I cannot reproduce on my machine, but I think @cgiffard said he could as well ... so this issue may not be azure specific.

Specifically What Works

These are the things that I noted as working after I removed the partials referenced in default.hbs in the admin views.

  1. The blog and it's default theme. Caveat: I haven't looked, but I don't think casper uses partials, so that may not work as well for themes.
  2. Content viewing and editing, including image uploads.
  3. User settings.
  4. Blog settings.

So as you can see really about 95% of it works, its just those darn partials. Might be worth trying to find someone at Microsoft who can help us take a look, or possibly seeing if @cgiffard has some time to step through the express-hbs module on his machine.

Summary of Setup Steps

These are the steps I took to deploy to Azure from my Windows 8 box. Pretty close to the standard deployment notes here.

  1. Get latest from GitHub.
  2. Run grunt build.
  3. Take the build output and place in another folder.
  4. Go to that folder, create a file called server.js.
  5. In the server.js file, all you need is one line: var GhostServer = require('./index');.
  6. Open core\server.js and find the line for server.listen. Swap ghost.config().server.port for process.env.PORT || ghost.config().server.port.
  7. Register for Windows Azure.
  8. Add a new website using Quick Create, select Local Git Respository as the deployment method.
  9. Navigate to the build output copied in step 3.
  10. Open a command prompt in the current folder.
  11. Run git init.
  12. Run git add --all && git commit -m "Initial Deployment".
  13. Run git remote add azure [URL OF DEPLOYMENT]. Note the git url in the screenshot below.
    git-instructions
  14. Run git push azure master.
  15. Access the website.
  16. Profit. 💸
@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Sep 19, 2013

Member

I have one question - lots of the platforms like nodejitsu etc work fine until you redeploy. Redeploying overwrites whatever you had in terms of DB & uploaded images.

Any idea whether that's the case with azure?

Member

ErisDS commented Sep 19, 2013

I have one question - lots of the platforms like nodejitsu etc work fine until you redeploy. Redeploying overwrites whatever you had in terms of DB & uploaded images.

Any idea whether that's the case with azure?

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Sep 19, 2013

Member

@ErisDS I have deployed to it about a dozen times, and in the middle I created a post with an image in it. My user account remained valid throughout the duration (evidenced by the fact when I would hit /ghost/signup/ it would always redirect to /ghost/ before crapping out on the partials. Also, my custom post and image in it were maintained throughout the last 3-4 deploys.

Mind you I did not have the database or any images in the deploy and that I was deploying via git, meaning that git was also taking into account the .gitignore file before copying files to the server.

In summary, my understanding is that Azure actually deploys changesets when possible, as opposed to copying everything. If you were to use dropbox as your deployment source on Azure, I couldn't say that we would see the same behavior -- I can test this tomorrow though and update the item.

Member

gotdibbs commented Sep 19, 2013

@ErisDS I have deployed to it about a dozen times, and in the middle I created a post with an image in it. My user account remained valid throughout the duration (evidenced by the fact when I would hit /ghost/signup/ it would always redirect to /ghost/ before crapping out on the partials. Also, my custom post and image in it were maintained throughout the last 3-4 deploys.

Mind you I did not have the database or any images in the deploy and that I was deploying via git, meaning that git was also taking into account the .gitignore file before copying files to the server.

In summary, my understanding is that Azure actually deploys changesets when possible, as opposed to copying everything. If you were to use dropbox as your deployment source on Azure, I couldn't say that we would see the same behavior -- I can test this tomorrow though and update the item.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Sep 19, 2013

Member

👍 If you could test that tomorrow, that would be fab, the more info we have the easier it is to fix. Left open in 0.4 til that bit is done then will close.

Member

ErisDS commented Sep 19, 2013

👍 If you could test that tomorrow, that would be fab, the more info we have the easier it is to fix. Left open in 0.4 til that bit is done then will close.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Sep 21, 2013

Member

Someone on twitter says they have this working.

Member

ErisDS commented Sep 21, 2013

Someone on twitter says they have this working.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Sep 21, 2013

Member

Thought I had updated the issue. I confirmed the dropbox deployment didn't overwrite anything.

I did see notes on the howtoinstallghost.com site for azure, but the method they used was basically utilizing a VPS. What I was testing out was the shared hosting aspect. Maybe leave this issue open for the shared hosting aspect?

Member

gotdibbs commented Sep 21, 2013

Thought I had updated the issue. I confirmed the dropbox deployment didn't overwrite anything.

I did see notes on the howtoinstallghost.com site for azure, but the method they used was basically utilizing a VPS. What I was testing out was the shared hosting aspect. Maybe leave this issue open for the shared hosting aspect?

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Sep 22, 2013

Member

@ErisDS Looks like someone on twitter was able to pinpoint the issue I described. It turns out the __dirname variable is a UNC path for Azure and node-glob does not seem to handle those types of paths well, thus leading to express-hbs not handling those types of paths well.

I think we have a couple of options:

  1. We can try submitting a PR against node-glob for a fix, then hoping it gets applied to express-hbs.
  2. We can try submitting a PR against express-hbs and try to get them to switch from glob to something like readdirp.
  3. We can create our own fork/version of express-hbs

I feel like this would be actually pretty simple to include our own fork/version of express-hbs. Meanwhile, we can also try opening up channels to both the problematic repos' owner's and see if we can't get it fixed in there so we could switch back eventually.

Member

gotdibbs commented Sep 22, 2013

@ErisDS Looks like someone on twitter was able to pinpoint the issue I described. It turns out the __dirname variable is a UNC path for Azure and node-glob does not seem to handle those types of paths well, thus leading to express-hbs not handling those types of paths well.

I think we have a couple of options:

  1. We can try submitting a PR against node-glob for a fix, then hoping it gets applied to express-hbs.
  2. We can try submitting a PR against express-hbs and try to get them to switch from glob to something like readdirp.
  3. We can create our own fork/version of express-hbs

I feel like this would be actually pretty simple to include our own fork/version of express-hbs. Meanwhile, we can also try opening up channels to both the problematic repos' owner's and see if we can't get it fixed in there so we could switch back eventually.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Sep 23, 2013

Member

@jgable and I have both submitted PR's to express-hbs and had them accepted within a few hours. Providing the PR comes with an explanation of why the change has been made I believe that is the best course of action.

Member

ErisDS commented Sep 23, 2013

@jgable and I have both submitted PR's to express-hbs and had them accepted within a few hours. Providing the PR comes with an explanation of why the change has been made I believe that is the best course of action.

ErisDS added a commit that referenced this issue Oct 7, 2013

@jbillmann

This comment has been minimized.

Show comment
Hide comment
@jbillmann

jbillmann Oct 10, 2013

Member

I'm actually the guy from Twitter who worked with @gotdibbs on this and unearthed #875 and #876. 👍

I did write up a post on my blog on how to get 0.3.0 up and running, but assuming these fixes work in 0.3.2 (I haven't tested them yet, but am planning on it), the set of steps I described (in conjunction with those above) could be optimized for easier public consumption.

I've actually done a lot of Azure work in my day job (shhh,don't tell anybody 😉 ) and could help put together a doc - including answers to questions about the shared hosting, pricing and file storage limitations.

Member

jbillmann commented Oct 10, 2013

I'm actually the guy from Twitter who worked with @gotdibbs on this and unearthed #875 and #876. 👍

I did write up a post on my blog on how to get 0.3.0 up and running, but assuming these fixes work in 0.3.2 (I haven't tested them yet, but am planning on it), the set of steps I described (in conjunction with those above) could be optimized for easier public consumption.

I've actually done a lot of Azure work in my day job (shhh,don't tell anybody 😉 ) and could help put together a doc - including answers to questions about the shared hosting, pricing and file storage limitations.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 10, 2013

Member

Welcome @jbillmann!! Glad to have someone else from Microsoft-land around! Funnily enough I literally just was trying out 0.3.2 and it seems to still be balking on loading partials :(

I think it might actually be because of the bump to express 3.4.x. Express is passing the _express3 function in express-hbs an options object which now appears to have options.cache set to true. In looking at express-hbs's source, it appears as though it expects that to be falsey before cachePartials is invoked.

I'm actually heading out for USA v. Jamaica and for the weekend but if you have time to dive into it a bit further and possibly come up with a fix to submit to express-hbs that would be awesome. Assuming that options.cache originally intended to denote that the partials had been cached already, my guess would be that the fix is going to be to use a different variable to check if the partials are already cached and to actually set that variable.

Edit: I just looked briefly looked at express and connect's updates and don't see anything, so this may be something we've done to ourselves.

Member

gotdibbs commented Oct 10, 2013

Welcome @jbillmann!! Glad to have someone else from Microsoft-land around! Funnily enough I literally just was trying out 0.3.2 and it seems to still be balking on loading partials :(

I think it might actually be because of the bump to express 3.4.x. Express is passing the _express3 function in express-hbs an options object which now appears to have options.cache set to true. In looking at express-hbs's source, it appears as though it expects that to be falsey before cachePartials is invoked.

I'm actually heading out for USA v. Jamaica and for the weekend but if you have time to dive into it a bit further and possibly come up with a fix to submit to express-hbs that would be awesome. Assuming that options.cache originally intended to denote that the partials had been cached already, my guess would be that the fix is going to be to use a different variable to check if the partials are already cached and to actually set that variable.

Edit: I just looked briefly looked at express and connect's updates and don't see anything, so this may be something we've done to ourselves.

@jbillmann

This comment has been minimized.

Show comment
Hide comment
@jbillmann

jbillmann Oct 10, 2013

Member

Thanks! 😄

Actually, I also have to head out tonight for a weekend mini-trip - but I can certainly take a look at this on Sunday night.

I do know that bumping express to 3.4.x worked with out 0.3.0 - we'll see.

Keep ya posted or vice versa.

Member

jbillmann commented Oct 10, 2013

Thanks! 😄

Actually, I also have to head out tonight for a weekend mini-trip - but I can certainly take a look at this on Sunday night.

I do know that bumping express to 3.4.x worked with out 0.3.0 - we'll see.

Keep ya posted or vice versa.

@jbillmann

This comment has been minimized.

Show comment
Hide comment
@jbillmann

jbillmann Oct 16, 2013

Member

@gotdibbs Having NODE_ENV set to production will have an incoming options.cache, within express-hbs, set to true via express. The reason this isn't a problem with version 0.2.2 of express-hbs is that prior to your PR, barc/express-hbs@2b0e370, it would always invoke cachePartials within express3 if there was a partialsDir regardless of options.cache.

if (partialsDir) cachePartials();

Looking at the history of hbs.js within express-hbs, it seems as though this line was intentionally added at some point, but I'm unsure of the context?

Here's where things get really odd. If I add that line of code back in just for proof, fs.realpath within readdirp gets goofy. It does not fire the callback if NODE_ENV is set to production and the path consists of many directories (>7, just like you would see in Azure)... otherwise it always seems to work? Facepalm. I'm at a loss for why this is occurring?

@ErisDS Looking at the comments surrounding the reopen of #875, I think we can take comfort in knowing that it looks as though version 3.4.0 of express is not at odds with version 0.3.0 of express-hbs for this particular issue, rather the PR above unearthed some odd logic with express-hbs caching partials that would be at odds with mostly any version of express.

Member

jbillmann commented Oct 16, 2013

@gotdibbs Having NODE_ENV set to production will have an incoming options.cache, within express-hbs, set to true via express. The reason this isn't a problem with version 0.2.2 of express-hbs is that prior to your PR, barc/express-hbs@2b0e370, it would always invoke cachePartials within express3 if there was a partialsDir regardless of options.cache.

if (partialsDir) cachePartials();

Looking at the history of hbs.js within express-hbs, it seems as though this line was intentionally added at some point, but I'm unsure of the context?

Here's where things get really odd. If I add that line of code back in just for proof, fs.realpath within readdirp gets goofy. It does not fire the callback if NODE_ENV is set to production and the path consists of many directories (>7, just like you would see in Azure)... otherwise it always seems to work? Facepalm. I'm at a loss for why this is occurring?

@ErisDS Looking at the comments surrounding the reopen of #875, I think we can take comfort in knowing that it looks as though version 3.4.0 of express is not at odds with version 0.3.0 of express-hbs for this particular issue, rather the PR above unearthed some odd logic with express-hbs caching partials that would be at odds with mostly any version of express.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 17, 2013

Member

@jbillmann I just took the latest and pushed it to azure websites and it seems to be working for me with a slightly modified version of express-hbs v0.3.0. Nothing but the defaults in iisnode.yml or in web.config (env set to prod of course). To set the startup script I just did the server.js + require('./index') as mentioned above. Also interesting is that I didn't have to do anything with express 3.4...

I tried two different modifications (both of which worked), the first was stripping out the check for options.cache in the loadDefaultLayout function. The second was setting a local isCached variable to true after paritals have been cached and changing the check in loadDefaultLayout to be if (options.cache && !isCached && partialsDir). Edit: for clarity's sake, here's my last update to hbs.js in gist form: https://gist.github.com/gotdibbs/70e7c53f65cb49c58480

Not sure if maybe you just needed to stop and start your website after making a change earlier? You can see my test instance working here. Username is ghost@tryghost.org and password is Sl1m3rson.

Member

gotdibbs commented Oct 17, 2013

@jbillmann I just took the latest and pushed it to azure websites and it seems to be working for me with a slightly modified version of express-hbs v0.3.0. Nothing but the defaults in iisnode.yml or in web.config (env set to prod of course). To set the startup script I just did the server.js + require('./index') as mentioned above. Also interesting is that I didn't have to do anything with express 3.4...

I tried two different modifications (both of which worked), the first was stripping out the check for options.cache in the loadDefaultLayout function. The second was setting a local isCached variable to true after paritals have been cached and changing the check in loadDefaultLayout to be if (options.cache && !isCached && partialsDir). Edit: for clarity's sake, here's my last update to hbs.js in gist form: https://gist.github.com/gotdibbs/70e7c53f65cb49c58480

Not sure if maybe you just needed to stop and start your website after making a change earlier? You can see my test instance working here. Username is ghost@tryghost.org and password is Sl1m3rson.

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Oct 17, 2013

Just tried it. Works great!

I work on Azure Web Sites, and it's awesome to see Ghost running on there :)

davidebbo commented Oct 17, 2013

Just tried it. Works great!

I work on Azure Web Sites, and it's awesome to see Ghost running on there :)

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 17, 2013

Member

@davidebbo Wooo! Thanks for giving it a shot. 🎈 🍰 I'll work on getting together a cleaner PR against express-hbs.

Love the platform btw, it's grown a lot since I first started using it three years ago and I'm amazed at how much stuff really does just work up there.

Member

gotdibbs commented Oct 17, 2013

@davidebbo Wooo! Thanks for giving it a shot. 🎈 🍰 I'll work on getting together a cleaner PR against express-hbs.

Love the platform btw, it's grown a lot since I first started using it three years ago and I'm amazed at how much stuff really does just work up there.

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Oct 17, 2013

@gotdibbs Thanks for the feedback!

BTW relating to your initial comment "if you had just a free account, you wouldn't have file access and things like SQLite and uploading images would break altogether". Actually, that all works fine with a free site. The main difference is that you get lower quotas (CPU, Memory, Disk), but it's usually enough to get started.

davidebbo commented Oct 17, 2013

@gotdibbs Thanks for the feedback!

BTW relating to your initial comment "if you had just a free account, you wouldn't have file access and things like SQLite and uploading images would break altogether". Actually, that all works fine with a free site. The main difference is that you get lower quotas (CPU, Memory, Disk), but it's usually enough to get started.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 17, 2013

Member

@davidebbo I noticed that after my trial expired actually :) thanks for the clarification though!

Member

gotdibbs commented Oct 17, 2013

@davidebbo I noticed that after my trial expired actually :) thanks for the clarification though!

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 18, 2013

Member

Pushed a cleaner fix to express-hbs here: barc/express-hbs#24. I confirmed this fix also works in my instance on azure and on the vagrant box.

Member

gotdibbs commented Oct 18, 2013

Pushed a cleaner fix to express-hbs here: barc/express-hbs#24. I confirmed this fix also works in my instance on azure and on the vagrant box.

@shanselman

This comment has been minimized.

Show comment
Hide comment
@shanselman

shanselman Oct 18, 2013

Yay!

Scott Hanselman

On Oct 17, 2013, at 7:19 PM, William Dibbern notifications@github.com wrote:

Pushed a cleaner fix to express-hbs here: barc/express-hbs#24. I confirmed this fix also works in my instance on azure and on the vagrant box.


Reply to this email directly or view it on GitHub.

shanselman commented Oct 18, 2013

Yay!

Scott Hanselman

On Oct 17, 2013, at 7:19 PM, William Dibbern notifications@github.com wrote:

Pushed a cleaner fix to express-hbs here: barc/express-hbs#24. I confirmed this fix also works in my instance on azure and on the vagrant box.


Reply to this email directly or view it on GitHub.

@jbillmann

This comment has been minimized.

Show comment
Hide comment
@jbillmann

jbillmann Oct 18, 2013

Member

@gotdibbs Nice work! I also just deployed it using your gist and it works like a charm! 👍 I have no idea why I was seeing the really, really odd readdirp/fs.realpath issues the other night when using a flavor of the hbs.js PR you just made - I'll just chalk that up to lack of sleep. 😪

Just for clarification, an overall successful deployment of Ghost to Azure will not only require your PR, but also a bump of express to 3.4.0.

Member

jbillmann commented Oct 18, 2013

@gotdibbs Nice work! I also just deployed it using your gist and it works like a charm! 👍 I have no idea why I was seeing the really, really odd readdirp/fs.realpath issues the other night when using a flavor of the hbs.js PR you just made - I'll just chalk that up to lack of sleep. 😪

Just for clarification, an overall successful deployment of Ghost to Azure will not only require your PR, but also a bump of express to 3.4.0.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 18, 2013

Member

@jbillmann Thanks! 🍰

Just for clarity's sake, Ghost is usable without the bump to express v3.4.0 right? It's something with the error templates that it has an issue with? Perhaps that is something we can patch directly in Ghost temporarily if that's the case.

Member

gotdibbs commented Oct 18, 2013

@jbillmann Thanks! 🍰

Just for clarity's sake, Ghost is usable without the bump to express v3.4.0 right? It's something with the error templates that it has an issue with? Perhaps that is something we can patch directly in Ghost temporarily if that's the case.

@jbillmann

This comment has been minimized.

Show comment
Hide comment
@jbillmann

jbillmann Oct 18, 2013

Member

@gotdibbs Yup, Ghost would still usable without express 3.4.0 - you'll just see issues with error templates such as 404's (AFAIK)...

Hmm, I'm not sure a patch for that within Ghost will be possible. At the end of the day, we're always working with a path in Azure that starts with '\' and express 3.3.* will process that as a non-absolute path:

expressjs/express@9e406df

express/lib/view.js

...
View.prototype.lookup = function(path){
    var ext = this.ext;

    // <path>.<engine>
    if (!utils.isAbsolute(path)) path = join(this.root, path);
    if (exists(path)) return path;

    // <path>/index.<engine>
    path = join(dirname(path), basename(path, ext), 'index' + ext);
    if (exists(path)) return path;
};
...
Member

jbillmann commented Oct 18, 2013

@gotdibbs Yup, Ghost would still usable without express 3.4.0 - you'll just see issues with error templates such as 404's (AFAIK)...

Hmm, I'm not sure a patch for that within Ghost will be possible. At the end of the day, we're always working with a path in Azure that starts with '\' and express 3.3.* will process that as a non-absolute path:

expressjs/express@9e406df

express/lib/view.js

...
View.prototype.lookup = function(path){
    var ext = this.ext;

    // <path>.<engine>
    if (!utils.isAbsolute(path)) path = join(this.root, path);
    if (exists(path)) return path;

    // <path>/index.<engine>
    path = join(dirname(path), basename(path, ext), 'index' + ext);
    if (exists(path)) return path;
};
...
@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 18, 2013

Member

@jbillmann Got it, thanks for the clarification. I will check with @ErisDS and see if we can nail down what the issues with switching to 3.4 were.

Member

gotdibbs commented Oct 18, 2013

@jbillmann Got it, thanks for the clarification. I will check with @ErisDS and see if we can nail down what the issues with switching to 3.4 were.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Oct 19, 2013

Member

Yo guys! I'm super excited about getting full support for Azure :)
Basically, the upgrade to express and express-hbs was originally in 0.3.2, but I noticed quite last minute that it had utterly broken file uploads see here. I decided that incorporating a minor version bump to express, which was not necessarily backwards compatible, was the wrong thing for a patch version of Ghost.

However, I did put a fix for this into master, whilst I knew what it was, but forgot to re-bump express & express-hbs. I am not aware of any other problems, but that in itself was the problem - I've no idea how much has changed / might have broken. We should be ok to do this bump in master, the code will get much more testing and coverage before 0.4 so we can find any issues.

In fact, I really need to bump all package versions.

Member

ErisDS commented Oct 19, 2013

Yo guys! I'm super excited about getting full support for Azure :)
Basically, the upgrade to express and express-hbs was originally in 0.3.2, but I noticed quite last minute that it had utterly broken file uploads see here. I decided that incorporating a minor version bump to express, which was not necessarily backwards compatible, was the wrong thing for a patch version of Ghost.

However, I did put a fix for this into master, whilst I knew what it was, but forgot to re-bump express & express-hbs. I am not aware of any other problems, but that in itself was the problem - I've no idea how much has changed / might have broken. We should be ok to do this bump in master, the code will get much more testing and coverage before 0.4 so we can find any issues.

In fact, I really need to bump all package versions.

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Oct 21, 2013

I still can't upload images. Even with 0.33 version.

luisrudge commented Oct 21, 2013

I still can't upload images. Even with 0.33 version.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Oct 21, 2013

Member

@luisrudge I don't think this is the place for this comment. Can you please open a thread on the forum as this sounds like a technical support problem - there is nothing wrong with image uploads in Ghost, but there are some environment problems you may be having.

Member

ErisDS commented Oct 21, 2013

@luisrudge I don't think this is the place for this comment. Can you please open a thread on the forum as this sounds like a technical support problem - there is nothing wrong with image uploads in Ghost, but there are some environment problems you may be having.

ErisDS added a commit that referenced this issue Oct 21, 2013

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Oct 21, 2013

@ErisDS sorry, i thought this was the place because i'm running it on windows azure web sites and the upload error is a known issue with this environment.

luisrudge commented Oct 21, 2013

@ErisDS sorry, i thought this was the place because i'm running it on windows azure web sites and the upload error is a known issue with this environment.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Oct 24, 2013

Member

@luisrudge there is no known problem with image uploads on Windows Azure. @gotdibbs @jbillmann can you confirm this?

What I was saying in my comment was that image uploads would have been broken for all Ghost users if the change we are talking about had been merged in 0.3.2 but it was taken out.

Member

ErisDS commented Oct 24, 2013

@luisrudge there is no known problem with image uploads on Windows Azure. @gotdibbs @jbillmann can you confirm this?

What I was saying in my comment was that image uploads would have been broken for all Ghost users if the change we are talking about had been merged in 0.3.2 but it was taken out.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 24, 2013

Member

@ErisDS You speak the truth. Image uploads have always worked a-ok on all the azure test deploys I've run.

Member

gotdibbs commented Oct 24, 2013

@ErisDS You speak the truth. Image uploads have always worked a-ok on all the azure test deploys I've run.

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Oct 24, 2013

@shanselman @ErisDS well, I must have done something wrong. I'm still getting this error:

Failed to load resource: the server responded with a status of 403 (Forbidden) http://luisrudge.azurewebsites.net/ghost/upload/

I'm deploying with dropbox though.. I don't know if it's related..

luisrudge commented Oct 24, 2013

@shanselman @ErisDS well, I must have done something wrong. I'm still getting this error:

Failed to load resource: the server responded with a status of 403 (Forbidden) http://luisrudge.azurewebsites.net/ghost/upload/

I'm deploying with dropbox though.. I don't know if it's related..

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Oct 24, 2013

Member

@luisrudge have you raised this on the forum? It's likely an environment problem, not a bug in Ghost

Member

ErisDS commented Oct 24, 2013

@luisrudge have you raised this on the forum? It's likely an environment problem, not a bug in Ghost

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Oct 24, 2013

Ok, i'll try the forum then. Thanks!

2013/10/24 Hannah Wolfe notifications@github.com

@luisrudge https://github.com/luisrudge have you raised this on the
forum? It's likely an environment problem, not a bug in Ghost


Reply to this email directly or view it on GitHubhttps://github.com/TryGhost/Ghost/issues/830#issuecomment-26990702
.

luisrudge commented Oct 24, 2013

Ok, i'll try the forum then. Thanks!

2013/10/24 Hannah Wolfe notifications@github.com

@luisrudge https://github.com/luisrudge have you raised this on the
forum? It's likely an environment problem, not a bug in Ghost


Reply to this email directly or view it on GitHubhttps://github.com/TryGhost/Ghost/issues/830#issuecomment-26990702
.

@jbillmann

This comment has been minimized.

Show comment
Hide comment
@jbillmann

jbillmann Oct 24, 2013

Member

I have not had any issues with image uploads in Azure and that includes running with the master as recently as yesterday evening... (and probably more Azure deployments than I care to admit 😒 )

That said, I haven't done any Dropbox deploys to Azure.

@luisrudge If you are unsuccessful in the forums or this seems to be a recurring issue with Dropbox, I'll try and take a look (of course, ping me outside this thread 😉 👍 ).

Member

jbillmann commented Oct 24, 2013

I have not had any issues with image uploads in Azure and that includes running with the master as recently as yesterday evening... (and probably more Azure deployments than I care to admit 😒 )

That said, I haven't done any Dropbox deploys to Azure.

@luisrudge If you are unsuccessful in the forums or this seems to be a recurring issue with Dropbox, I'll try and take a look (of course, ping me outside this thread 😉 👍 ).

@shanselman

This comment has been minimized.

Show comment
Hide comment
@shanselman

shanselman Oct 24, 2013

Let's discuss elsewhere.

On Oct 24, 2013, at 5:34 AM, Luís Rudge notifications@github.com wrote:

@shanselman @ErisDS well, I must have done something wrong. I'm still getting this error:

Failed to load resource: the server responded with a status of 403 (Forbidden) http://luisrudge.azurewebsites.net/ghost/upload/
I'm deploying with dropbox though.. I don't know if it's related..


Reply to this email directly or view it on GitHub.

shanselman commented Oct 24, 2013

Let's discuss elsewhere.

On Oct 24, 2013, at 5:34 AM, Luís Rudge notifications@github.com wrote:

@shanselman @ErisDS well, I must have done something wrong. I'm still getting this error:

Failed to load resource: the server responded with a status of 403 (Forbidden) http://luisrudge.azurewebsites.net/ghost/upload/
I'm deploying with dropbox though.. I don't know if it's related..


Reply to this email directly or view it on GitHub.

gotdibbs added a commit to gotdibbs/Ghost that referenced this issue Oct 24, 2013

Bumped express-hbs version
Fixes #830

- Bumped `express-hbs` version to `v0.5` which includes our updates to
support azure (UNC paths) and a fix for caching of partials.
@chadly

This comment has been minimized.

Show comment
Hide comment
@chadly

chadly Oct 26, 2013

One thing to note when running in Azure websites, IIS will hide the custom error pages for ghost if you don't change any of the default settings. A web.config file is required with <httpErrors existingResponse="PassThrough" /> as described here in order to show the nice ghost error pages.

And since I had to add a web.config anyway, in order to get my site running, I included that line in addition to this:

<handlers>
    <add name="iisnode" path="index.js" verb="*" modules="iisnode" />
</handlers>

rather than including a separate server.js file that requires index.js.

I'm not sure if you want to include a web.config in the repo, but if you like, I can create a pull request with the "default" web.config to get ghost up and running on IIS (on azure websites or wherever else IIS is being used).

chadly commented Oct 26, 2013

One thing to note when running in Azure websites, IIS will hide the custom error pages for ghost if you don't change any of the default settings. A web.config file is required with <httpErrors existingResponse="PassThrough" /> as described here in order to show the nice ghost error pages.

And since I had to add a web.config anyway, in order to get my site running, I included that line in addition to this:

<handlers>
    <add name="iisnode" path="index.js" verb="*" modules="iisnode" />
</handlers>

rather than including a separate server.js file that requires index.js.

I'm not sure if you want to include a web.config in the repo, but if you like, I can create a pull request with the "default" web.config to get ghost up and running on IIS (on azure websites or wherever else IIS is being used).

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 26, 2013

Member

@chadly Most excellent point! I've added that line to the web.config file that I've been using and was going to be including in our documentation for installing under Windows (currently the docs reference just running Ghost from the command prompt, I'm going to be submitting a PR to include the suggestion to run under iisnode and appropriate instructions).

I personally wouldn't mind a sort of "recommended" web.config in the repository myself, but I wonder what @ErisDS thinks? Considering it is host specific I could see it going either way.

As well, here is the current web.config I was referencing: https://gist.github.com/gotdibbs/7141615

Member

gotdibbs commented Oct 26, 2013

@chadly Most excellent point! I've added that line to the web.config file that I've been using and was going to be including in our documentation for installing under Windows (currently the docs reference just running Ghost from the command prompt, I'm going to be submitting a PR to include the suggestion to run under iisnode and appropriate instructions).

I personally wouldn't mind a sort of "recommended" web.config in the repository myself, but I wonder what @ErisDS thinks? Considering it is host specific I could see it going either way.

As well, here is the current web.config I was referencing: https://gist.github.com/gotdibbs/7141615

@shanselman

This comment has been minimized.

Show comment
Hide comment
@shanselman

shanselman Oct 26, 2013

Personally, I think the server.js single line is preferred, and azure will (and does) auto generate the web.config.

From: William Dibbern
Sent: ‎Saturday‎, ‎October‎ ‎26‎, ‎2013 ‎11‎:‎39‎ ‎AM
To: TryGhost/Ghost
Cc: Scott Hanselman

@chadly Most excellent point! I've added that line to the web.config file that I've been using and was going to be including in our documentation for installing under Windows (currently the docs reference just running Ghost from the command prompt, I'm going to be submitting a PR to include the suggestion to run under iisnode and appropriate instructions).

I personally wouldn't mind a sort of "recommended" web.config in the repository myself, but I wonder what @ErisDS thinks? Considering it is host specific I could see it going either way.

As well, here is the current web.config I was referencing: https://gist.github.com/gotdibbs/7141615


Reply to this email directly or view it on GitHub.

shanselman commented Oct 26, 2013

Personally, I think the server.js single line is preferred, and azure will (and does) auto generate the web.config.

From: William Dibbern
Sent: ‎Saturday‎, ‎October‎ ‎26‎, ‎2013 ‎11‎:‎39‎ ‎AM
To: TryGhost/Ghost
Cc: Scott Hanselman

@chadly Most excellent point! I've added that line to the web.config file that I've been using and was going to be including in our documentation for installing under Windows (currently the docs reference just running Ghost from the command prompt, I'm going to be submitting a PR to include the suggestion to run under iisnode and appropriate instructions).

I personally wouldn't mind a sort of "recommended" web.config in the repository myself, but I wonder what @ErisDS thinks? Considering it is host specific I could see it going either way.

As well, here is the current web.config I was referencing: https://gist.github.com/gotdibbs/7141615


Reply to this email directly or view it on GitHub.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 26, 2013

Member

I've thought about it a bit more and I believe there are a couple reasons why I believe the web.config approach is better:

  1. We probably don't want to start cluttering the repository with host-specific code. This means no additional server.js file just for Azure. As discussed before in our email thread, we don't really have a strong reason to rename index.js to server.js for any other reason than Azure support and including a file that just requires index.js might lead to more confusion than it is worth.
  2. Currently I do not believe the generated web.config file includes the necessary configuration line that @chadly mentions.
  3. At the end of the day I think an xml-based configuration change is much more appealing to users than a code change in order to get Ghost up and running on their platform of choice.
Member

gotdibbs commented Oct 26, 2013

I've thought about it a bit more and I believe there are a couple reasons why I believe the web.config approach is better:

  1. We probably don't want to start cluttering the repository with host-specific code. This means no additional server.js file just for Azure. As discussed before in our email thread, we don't really have a strong reason to rename index.js to server.js for any other reason than Azure support and including a file that just requires index.js might lead to more confusion than it is worth.
  2. Currently I do not believe the generated web.config file includes the necessary configuration line that @chadly mentions.
  3. At the end of the day I think an xml-based configuration change is much more appealing to users than a code change in order to get Ghost up and running on their platform of choice.
@shanselman

This comment has been minimized.

Show comment
Hide comment
@shanselman

shanselman Oct 26, 2013

So if there's a web.config (vestigial for non windows folks) then it's just download the zip and deploy, right?

On Oct 26, 2013, at 3:19 PM, William Dibbern notifications@github.com wrote:

I've thought about it a bit more and I believe there are a couple reasons why I believe the web.config approach is better:

We probably don't want to start cluttering the repository with host-specific code. This means no additional server.js file just for Azure. As discussed before in our email thread, we don't really have a strong reason to rename index.js to server.js for any other reason than Azure support and including a file that just requires index.js might lead to more confusion than it is worth.
Currently I do not believe the generated web.config file includes the necessary configuration line that @chadly mentions.
At the end of the day I think an xml-based configuration change is much more appealing to users than a code change in order to get Ghost up and running on their platform of choice.

Reply to this email directly or view it on GitHub.

shanselman commented Oct 26, 2013

So if there's a web.config (vestigial for non windows folks) then it's just download the zip and deploy, right?

On Oct 26, 2013, at 3:19 PM, William Dibbern notifications@github.com wrote:

I've thought about it a bit more and I believe there are a couple reasons why I believe the web.config approach is better:

We probably don't want to start cluttering the repository with host-specific code. This means no additional server.js file just for Azure. As discussed before in our email thread, we don't really have a strong reason to rename index.js to server.js for any other reason than Azure support and including a file that just requires index.js might lead to more confusion than it is worth.
Currently I do not believe the generated web.config file includes the necessary configuration line that @chadly mentions.
At the end of the day I think an xml-based configuration change is much more appealing to users than a code change in order to get Ghost up and running on their platform of choice.

Reply to this email directly or view it on GitHub.

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 26, 2013

Member

@shanselman Indeed that should be the case in general for Windows-based hosts. For Azure itself, @jbillmann is spearheading getting the gallery package together so that it's one click and done. 🍰

Member

gotdibbs commented Oct 26, 2013

@shanselman Indeed that should be the case in general for Windows-based hosts. For Azure itself, @jbillmann is spearheading getting the gallery package together so that it's one click and done. 🍰

@shanselman

This comment has been minimized.

Show comment
Hide comment
@shanselman

shanselman Oct 26, 2013

It's worth noting that neither solution solves the "keep it updated" issue.
Forgive my ignorance but will Ghost auto update one day?

FWIW, the gallery team is in my org, and I've build apps (including my own
blog) and put them in the gallery @jbillmann https://github.com/jbillmann if
you need help.

On Saturday, October 26, 2013, William Dibbern wrote:

@shanselman https://github.com/shanselman Indeed that should be the
case in general for Windows-based hosts. For Azure itself, @jbillmannhttps://github.com/jbillmannis spearheading getting the gallery package together so that it's one click
and done. [image: 🍰]


Reply to this email directly or view it on GitHubhttps://github.com/TryGhost/Ghost/issues/830#issuecomment-27157732
.

Scott Hanselman
Help me? http://hnsl.mn/fightdiabetes

shanselman commented Oct 26, 2013

It's worth noting that neither solution solves the "keep it updated" issue.
Forgive my ignorance but will Ghost auto update one day?

FWIW, the gallery team is in my org, and I've build apps (including my own
blog) and put them in the gallery @jbillmann https://github.com/jbillmann if
you need help.

On Saturday, October 26, 2013, William Dibbern wrote:

@shanselman https://github.com/shanselman Indeed that should be the
case in general for Windows-based hosts. For Azure itself, @jbillmannhttps://github.com/jbillmannis spearheading getting the gallery package together so that it's one click
and done. [image: 🍰]


Reply to this email directly or view it on GitHubhttps://github.com/TryGhost/Ghost/issues/830#issuecomment-27157732
.

Scott Hanselman
Help me? http://hnsl.mn/fightdiabetes

@gotdibbs

This comment has been minimized.

Show comment
Hide comment
@gotdibbs

gotdibbs Oct 26, 2013

Member

@shanselman I'll be working on the start of our upgrade magic with #1260 ... I'll be sure to keep Windows in mind as that's what I work with primarily :)

Member

gotdibbs commented Oct 26, 2013

@shanselman I'll be working on the start of our upgrade magic with #1260 ... I'll be sure to keep Windows in mind as that's what I work with primarily :)

jptacek added a commit to jptacek/Ghost that referenced this issue Nov 4, 2013

Bumped express-hbs version
Fixes #830

- Bumped `express-hbs` version to `v0.5` which includes our updates to
support azure (UNC paths) and a fix for caching of partials.

morficus pushed a commit to morficus/Ghost that referenced this issue Sep 4, 2014

morficus pushed a commit to morficus/Ghost that referenced this issue Sep 4, 2014

morficus pushed a commit to morficus/Ghost that referenced this issue Sep 4, 2014

Bumped express-hbs version
Fixes #830

- Bumped `express-hbs` version to `v0.5` which includes our updates to
support azure (UNC paths) and a fix for caching of partials.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment