find a new static site generator

[karthik]

to replace Jekyll.

[karthik]

another option is to hire a contractor who understands Jekyll well enough to resolve current issues and build an automatic deploy system.

[cboettig]

I'm happy for us to move away, we could just do what Jenny does with pure RStudio / pandoc. However, the Jekyll builds fine for me, I'm still not clear what the problem is. Where should I be looking for a description? Did you try building using the recipe in the Travis?

We can move to another templating platform that is richer than pandoc, but I'm not sure it is good to move from a system we all sort of know to one none of us knows?

[karthik]

However, the Jekyll builds fine for me, I'm still not clear what the problem is.

If it does, can you rsync the rendered _site to our server?

[karthik]

Works for me locally too. I pushed the failed version up to the site.

https://ropensci.org/blog/ (you can see the blurb of the post) click the link and you get a 404. add a .html and it renders

The same issue happened with the previous post on grant announcement day.

[cboettig]

Right. I don't think I have access to our server so I cannot debug things or rsync there (as mentioned in #215).

I suspect this is due to the Apache rewrite rules on the server, and things would be simpler with the fewer moving parts of ASO, but would need to log in to poke around.

[karthik]

I'll email you credentials. but I can also add your public key so you can ssh.

[sckott]

https://middlemanapp.com looks promising, played a bit with it

[karthik]

This is the .htaccess

#RewriteCond %{HTTPS} off
#RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L]
    RewriteBase /
    RewriteCond %{SERVER_PORT} !^443$
    RewriteRule ^(.*)?$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

ErrorDocument 404 /404.html

 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteRule ^([0-9a-zA-Z\_\-]+)$ $1.html
#RewriteRule ^blog/2015/11/19/hemlsley-trust-funding /blog/2015/11/19/hemlsley-trust-funding.html [L,R=301]

# RewriteCond %{HTTP_HOST} ^ropensci\.org$ [OR]
# RewriteCond %{HTTP_HOST} ^www\.ropensci\.org$

I tweeted a typo version in the link for the Helmsley post, hence the one off fix for that.

[karthik]

wonder if I could just delete the .htaccess and see what happens. There isn't one locally.

[karthik]

That didnt help. Currently even the renterz post does not go anywhere.

[cboettig]

So does everything look correct at http://ropensci.github.io/roweb ? It might be fastest to just drop a CNAME in there and host from there while we debug the rewrite issues on the server. Given that things are rendering fine locally for everyone this really seems like a server-side (apache or what not) config issue rather than a Jekyll generate issue.

[karthik]

It might be fastest to just drop a CNAME in there and host from there while we debug the rewrite issues on the server.

ok. I don't know how this would affect email. I also guess I'd have to do this on cloudfront. I'm basically out of time today (either that or I fly without any clean laundry) and don't expect to have time till next weekend. So someone else will have to do this:

Two things: Hopefully it wont break email (the forwarders are on ASM) Besides CNAME, I believe this would also require some config on cloudflare.

Out of curiosity, I don't understand how the site renders locally without a .htaccess to manage the rewrite rules. If it did generate one, we could just copy that over (there is nothing else special on ours).

[cboettig]

I don't believe that dropping in a CNAME would break email or anything else; that would still be handled on the ASO servers. I believe the recommended strategy here is to actually put www.ropensci.org in the CNAME file in the repo. This way it does not mess up email etc, just like any other domain.

While GitHub can be configured without a CNAME, only CNAME subdomains benefit from GitHub's very fast CDN, so www has that advantage too. Of course we want http://ropensci.org to resolve without the www, so we then do the standard thing in the DNS with an A level pointing at the apex domain, which should not disrupt email or anything.

This will have the side-effect of http://ropensci.org addresses being forwarded to http://www.ropensci.org.

Also, using GH-Pages means no https, (maybe that's okay since the site is static anyway so users aren't generating a lot of private data to encrypt?).

I believe this would just bypass CloudFlare; I don't believe we'd see any improvement by using CloudFlare CDN since we already have the GitHub CDN this way. (CloudFlare does support fake https but that's just stupid).

Question: Are there still files on the server that are not part of the GitHub repo but are still needed for deploy? (e.g. proprietary fonts, etc?) If not, starting with a clean directory on the server might help.

I can give this a go some time today if that sounds okay. Otherwise can see if I can fix the server side with a .htaccess. Will back up anything on the server so I don't destroy stuff.

Re rendering locally: when you render locally Ruby is actually launching it's own light-weight web server (WEBrick by default) which has it's own config and defaults about how it handles things like .html endings. Apparently it does the intelligent thing by default.

[karthik]

Are there still files on the server that are not part of the GitHub repo but are still needed for deploy? (e.g. proprietary fonts, etc?) If not, starting with a clean directory on the server might help.

Most sitewide fonts come from typekit now. Right now I'm juggling way too many things and cannot recall why we did not do this before (gh-pages and CNAME isn't new) but feel like I am missing some other rationale. I believe the icons and a couple of other things are on ASM but rebased out of this repo. So those would break.

[cboettig]

Looks like the .htaccess doesn't have a RewriteEngine On command?

For a minimal .htaccess maybe try:

ErrorDocument 404 /404.html

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([0-9a-zA-Z\_\-]+)$ $1.html

(I tried adding my ssh key to the server, but not sure what username it is being added under. ssh'ing just asks me for a password...)

Do we want to stick with the proprietary fonts and icons? Openly licensed ones have gotten pretty good (but then I have no design sense). Guess that could be a time-consuming redesign though. I think we could still have proprietary fonts on GH repo I suppose if we just made the repo itself private?

[karthik]

The new htaccess replacement didn't work.

The second blog post on the blog page (http://ropensci.org/blog/2015/09/24/rentrez-1-0-release) still doesn't work although the post above and below does. So the rewrite rule works for some but not others making troubleshooting a lot harder.

[cboettig]

Ah right! there's no \. in the last rewrite rule (RewriteRule ^([0-9a-zA-Z\_\-]+)$ $1.html ). Adding that should fix it.

Though it might be simpler/better to rename the post url to not have a 1.0 in it (like the hemsley post, which has a decimal in the page title but not the URL), though that could break links.

[cboettig]

Um, sorry, it's an underscore, not a period, that is causing the issues: note this URL works: http://ropensci.org/blog/2015/09/24/rentrez-1_0-release/

Not sure why it's getting converted to a hyphen in the blog.html page, but I still think removing the underscore and avoiding underscores in paths should at least make apache happy.

[cboettig]

So it does look like the Jekyll version you are running on the sever to build the site is being bitten by this issue: https://github.com/jekyll/jekyll/issues/4135 , and it really is turning _ to - in post.url. Looks like this is fixed in Jekyll >= 3.0.1, as well as not impacting versions before 3.0.0.

[karthik]

I tried removing all - and _ and still can't get it to work. Currently the survey post is just titled 2016-01-07-survey.md and generates http://ropensci.org/blog/2016/01/07/survey but that doesn't work either.

So avoid underscores? or avoid dashes? This problem didn't affect earlier posts.

[karthik]

But http://ropensci.org/blog/2016/01/07/survey.html works.

[karthik]

well I manually edited /blog/index.html to include the .html suffix for now. :astonished:

Of course, it will break with the next push of _site. But for now, the post is up there.

[cboettig]

Okay, just logged onto the server so I could screw with .htaccess. This should be working now: https://ropensci.org/blog/2016/01/07/survey

rentrez and other posts should be working even though they have _ in their name now too.

The following is the htaccess:

Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\.]+)$ $1.html [NC,L]

Note that it doesn't have the https rewrite that we had earlier, so we should add that back in if we want people to get automatically redirected to https (though most browsers will do that automatically if the person has previously visited the site under https). Anyway, the pages should all resolve equally well under either protocol.

[karthik]

Marked as successfully completed 🎉 🎈