Next Steps

[nodejs]

Next Steps

[mikeal]

@fhemberger can you edit the checklist add any additional work.

[diagramatics]

By the .md files, are they content writing? I'm able to help in any way I can if the quality of the weekly updates I churned out are satisfactory.

[fhemberger]

@diagramatics Uhm, at least I used the checkboxes for content migration from nodejs.org/iojs.org, not necessarily for content (re)write or editing, I think this will be the next step.

[mikeal]

@diagramatics @fhemberger Corrent, with the exception of the Resources page which I think should be something new and Docs WG should decide/write that.

[leo]

So this whole things isn't about making a real new site (including a different design), it's just about merging the contents of the io- and node-site, right?

Does this mean that a re-design would be completely inappropriate? Or at least suggestions for a new layout? Because if I take a look at the current state, nothing has changed regarding styles.

[fhemberger]

@leo A little bit of everything. ;) First of all, with the launch of the converged node/iojs v4 being scheduled for October, we want a unified website in place with well structured and up-to-date content. So this is what we're focussing on at the moment. Getting everything set-up (also for the localization teams to start), optimize the site's structure and revise the content.

During the process, we're also cleaning up the HTML and CSS. Design improvements are of cause welcome, but I guess for the moment we won't pursue a radical redesign.

[leo]

Ahh, okay!

Then I'll have a look into what needs to be done there and check back again when the re-design happens (since I'd like to help there in terms of development or appearance).

[fhemberger]

Added Governance, Working Groups, FAQ, ES6 and a 404 page.

[snostorm]

I added a rough start to the downloads page (iojs skewed right now) as well as starting to port over the i18n and linking handlebar helpers which were helpful in earlier i18n work on iojs.org. There's also some proof of concept work around a "download .md from external repo folders" hiding in the project now.

[mikeal]

Hey @rvagg and @nodejs/build are we going to mess up all the current download links in the migration to the new site if we don't have a new download service solution worked out?

[mikeal]

I just pushed a few big changes to the nav and footer.

• Moved "Resources" to "Docs" and put "API Docs" under "Docs"
  • We have way too much stuff in the top nav.
  • Having one area with docs called "Resources" next to another called "API Docs" was terribly confusing.
  • We can debate names all day but people looking for docs tend to look for the word "Docs" or "Documentation"
• Moved "/community" to "/contribute"
  • The entire project is built by the "community." Each section should have information about how the community maintains those resources.
  • The text I used for the top nav is "Get Involved" which is nice and action oriented.
• Removed bottom nav.
  • This nav was largely redundant and hardly anyone gets to the bottom anyway.
  • We'll probably need this space for the localizations at some point.

[mikeal]

Should we have a top level section called "Help"?

I'm not getting notifications for the all the form submissions for joining the foundation and there is a surprising number of support requests that come through simply because it's the only resources on the site that is a form.

[rvagg]

Not sure exactly what the question here is re downloads but here's my current thoughts on the matter:

• Move to download directory structure in use on iojs.org but keep it backward compatible like we do there, which means a /download/ directory to contain the different download types with /dist/ being a symlink to /download/release/ so it's basically like nodejs.org/dist
• Make io.js releases available in /download/io.js/ where that is what we have now in iojs.org/download, also ensure that iojs.org/download/ and iojs.org/dist continue to work as they do now with no interruption.
• Nothing breaks for existing releases, future releases follow roughly the same pattern in nodejs.org/dist so most existing expectations and assumptions still hold.
• When we move to a CDN for distributing, we'll just have to adapt over the top of this but we should prioritise backward-compatibility and introducing a CDN into the mix right now is just going to slow us down so we should push that out further.

Clear as mud?

[mikeal]

@rvagg our infra has the io.js releases, obviously, but do we have all the old node.js releases as well so that we don't break all the links to nodejs.org releases the moment we go live with the new site?

[rvagg]

@mikeal working on new infra atm, assume this is going to go live on different infra than we are using for iojs.org right now. Will make sure that all binaries are available so that nodejs.org feels the same to users.

One side item—can we have a catalogue of links from nodejs.org that are going to break as a result of this upgrade (if any) so we can add in redirects to the server config to avoid 404s please.

[mikeal]

One side item—can we have a catalogue of links from nodejs.org that are going to break as a result of this upgrade (if any) so we can add in redirects to the server config to avoid 404s please.

Very good point, we should put that on the checklist.

[snostorm]

Speaking of downloads. In trying to build the download/release pages (as in user friendly ones) we'll need a version of https://iojs.org/dist/index.json which works for all Node versions, past-and-future. I'm okay with it being two files -- one for the limited io.js line and one for Node -- as long as we can download them as part of the new.nodejs.org build process.

[rvagg]

@snostorm I can make that happen when we get new infra for this. Not going to touch the old infra though.

[snostorm]

@rvagg works for me :) Just wanted to mention the gap

[fhemberger]

One side item—can we have a catalogue of links from nodejs.org that are going to break as a result of this upgrade (if any) so we can add in redirects to the server config to avoid 404s please.

@rvagg Not complete yet, but should catch most of the cases:

rewrite ^/about/advisory-board/                                                     https://$server_name/en/about/organization/ permanent;
rewrite ^/about/advisory-board/members/                                             https://$server_name/en/about/organization/ permanent;
rewrite ^/about/organization/tsc-meetings/                                          https://$server_name/en/foundation/tsc/minutes/ permanent;
rewrite ^/about/organization/tsc-meetings/(.*?)/minutes.html                        https://$server_name/en/foundation/tsc/minutes/$1/ permanent;
rewrite ^/about/security/                                                           https://$server_name/en/security/ permanent;
rewrite ^/advisory-board/(.*)                                                       https://$server_name/en/about/organization/ permanent;
rewrite ^/contribute/                                                               ???? permanent;
rewrite ^/contribute/accepting_contributions.html                                   ???? permanent;
rewrite ^/contribute/becoming_collaborator.html                                     ???? permanent;
rewrite ^/contribute/code_contributions/                                            ???? permanent;
rewrite ^/contribute/code_contributions/workflow.html                               ???? permanent;
rewrite ^/documentation/                                                            ???? permanent;
rewrite ^/documentation/localization/                                               ???? permanent;
rewrite ^/documentation/tutorials/                                                  ???? permanent;
rewrite ^/foundation/blog.html                                                      https://$server_name/en/blog/ permanent;
rewrite ^/foundation/members.html                                                   https://$server_name/en/foundation/members/ permanent;

rewrite ^/images/foundation-visual-guidelines.pdf                                   https://$server_name/static/documents/foundation-visual-guidelines.pdf permanent;
rewrite ^/images/logos/js-black(.*)                                                 https://$server_name/static/images/logos/js-black$1 permanent;
rewrite ^/images/logos/nodejs-(.*)                                                  https://$server_name/static/images/logos/nodejs-$1 permanent;
rewrite ^/images/node-foundation-by-laws.pdf                                        https://$server_name/static/documents/node-foundation-by-laws.pdf permanent;
rewrite ^/images/.*trademark-policy.pdf                                             https://$server_name/static/documents/trademark-policy.pdf permanent;
rewrite ^/video/(.*)                                                                https://$server_name/static/video/$1 permanent;

http://blog.nodejs.org/\d{4}/\d{2}/\d{2}/(?:.*)?(v(?:ersion))?\d{1,2}\.\d{1,2}\.\d{1,2})(.*)    https://$server_name/en/blog/release/$1/ permanent;
http://blog.nodejs.org/(.*)                                                                   https://$server_name/en/blog/$1/ permanent;

[fhemberger]

Weekly news link is now automatically generated from blog/weekly-updates/*.md, please make sure to always add the variable date: YYYY-MM-DD to the YAML frontmatter for this to work.

[fhemberger]

By the way: I have access to nodejs.org, so if we need a preview site, maybe I can set something up (preferably with a GitHub hook).

[snostorm]

http://new-nodejs.iojs.org/ is "working" now, I just need to make some small tweaks to get the build steps to actually publish what's in ./dist whenever we push (right now it runs a placeholder script to match io.js)

Might not be worth hacking in to to the existing nodejs.org server as I believe @nodejs/build is winding up new servers to tie in to https://nodejs.org/dist/ for the 4.0 release.

[fhemberger]

@snostorm Ah, okay.

[phillipj]

Are the initial tasks up to date?

According to previous comments by @mikeal it looks like a couple of sections has been renamed

• Community -> Contribute
• Resources -> Docs

And contribute and downloads was closed with #37 and #35?

[mikeal]

@phillipj renamed in the checklist :)

[fhemberger]

I still would like to have the download-matrix from nodejs.org for the new site as well:

Also, what about additional platform builds? @mikeal @rvagg Do you know more about it?

[therebelrobot]

+1 to having the download matrix on the new site.

[therebelrobot]

Question: is there a specific design that the new site is based on? I'm trying to catch up with everything, and wanted to see about making styling fixes where needed, I just don't know where to find the assets (if any).

[fhemberger]

No, I took the basic visual design from nodejs.org, but started with fresh html/css. Assets have moved from /images to /static. If you need something from the old site, just copy it from nodejs.org for now.

[therebelrobot]

Kk. I'll be hopping in more in depth tonight, I just wanted to make sure I was moving in the right direction. :)

[rvagg]

status update on the @nodejs/build end:

• I've provisioned a new.nodejs.org and DNS is pointing to it, I've begun writing an ansible script to reconcile the setup from old & new and there some issues that I'll file separately for discussion, I'll also integrate @fhemberger's redirects there and it can all be edited via github by both website and build teams.
• We're working with CloudFlare to experiment with having them front the web server and handle the bulk of the load
• I just (finally!) got new wildcard SSL certs for *.iojs.org and *.nodejs.org owned by the Foundation, they are in my inbox but I haven't looked yet.

[phillipj]

Speaking of downloads and versions.. Should the site contain both io.js and node.js or just (the converged) node.js?

[fhemberger]

Both. There still needs to be some work done to integrate the builds automatically into the site.

[rvagg]

So, folks, you only have a temporary file in ./public/ which is what's copied into the live directory at build time, everything else is living in the root, can we come to an agreement about what actually gets published to the site and what directories to copy and what to not copy? It's doing a node_modules/.bin/gulp build at the moment, is this the wrong thing to be doing?

[fhemberger]

AFAIK @snostorm copied those parts from the old website. The site is now using npm run build (which is running the build.js command in the root folder) to generate all files into build.

I don't know what his plan was with the gulp file, if we don't need it anymore, we can simpla adjust the paths.

[mikeal]

ya, everything is in ./build, even static files get copied in there. the test server just serves that up (although we'll need to add a few routing rules soon).

[mikeal]

we have had some good progress today, I'm considering closing this Issue and filing a new one with a much more specific TODO list that we need to crank out in order to be live on time.

[rvagg]

OK, so, you want to npm run build and then rsync the contents of ./build into public?

[rvagg]

Site is live now @ https://new.nodejs.org/en/index.html

You have to use https for this or you'll be redirected to nodejs.org

There is no index.html in the root so you'll get a Forbidden from that, probably something you need to fix?

Config is evolving @ https://github.com/nodejs/build/pull/162/files (setup/www/resources/nodejs.org)

I've set up the github-webhook for this on that server so pushes to master should result in a build in the same way as on iojs.org although it does npm run build and copies the contents ./build/ to the public directory.

[rvagg]

Sorry, I should have waited, I'm going to wipe the server and run my script again to make sure it's complete so far.

Once we have confidence in the basics of the Ansible config then I might do an rsync of nodejs.org/dist/ and make it available to you there so we can move closer to live state. I'm also going to turn on CloudFlare's CDN for new.nodejs.org as soon as I'm able (hopefully before the weekend).

[fhemberger]

There is no index.html in the root so you'll get a Forbidden from that, probably something you need to fix?

@rvagg Can you please add a hard redirect in nginx.conf from / and index.html to /en/? Its way better than adding empty index.html files with meta redirects.

[rvagg]

ah, right, will do, I thought index.html was doing something fancy with language selection

[fhemberger]

No, but there's a separate nginx module allowing redirects based on the user's Accept-Language header. Maybe we can use this in the future.

[mikeal]

Closing this in favor of #58